Список тулів і корисних MCP серверів для мого воркшопчику сьогодні на DOU Day.
Використовувати будемо Cursor, але можна інші IDE, зокрема Windsurf, Copilot, Cline/Roo Code і т.д., просто в кожної буде своя специфіка.
Можна пробувати використовувати безкоштовні варіанти, але я буду показувати в платному курсорі, також бажано мати трохи грошей ($3-5 вистачить з головою) на Open AI API, Anthropic та Perplexity, можна використовувати OpenRouter, там є варіант з безкоштовними моделями.
MCP Сервери:
Context7 для доків https://context7.com/
Task Master AI для задач https://github.com/eyaltoledano/claude-task-master
Perplexity Ask для пошуку https://mcp.so/server/perplexity/ppl-ai
Використовувати будемо Cursor, але можна інші IDE, зокрема Windsurf, Copilot, Cline/Roo Code і т.д., просто в кожної буде своя специфіка.
Можна пробувати використовувати безкоштовні варіанти, але я буду показувати в платному курсорі, також бажано мати трохи грошей ($3-5 вистачить з головою) на Open AI API, Anthropic та Perplexity, можна використовувати OpenRouter, там є варіант з безкоштовними моделями.
MCP Сервери:
Context7 для доків https://context7.com/
Task Master AI для задач https://github.com/eyaltoledano/claude-task-master
Perplexity Ask для пошуку https://mcp.so/server/perplexity/ppl-ai
Cursor
Cursor - The AI Code Editor
Built to make you extraordinarily productive, Cursor is the best way to code with AI.
May 17
June 4
June 10
Що робити джунам, яких замінить AI?
Зараз активно розганяється тема про те що джуни не потрібні, бо “їх замінить AI”. Хайпувати на всяких фобіях дуже зручно, але чому треба боятися більше сеньйорам, а не джунам я вам зараз розкажу. І сеньйори, до речі, вже почали потроху скромніше бути в своїх хотілках, кілька днів тому на DOU з’явилося цікаве дослідження https://dou.ua/forums/topic/54181/
Важливий дісклеймер - я взагалі не підтримую думку що “AI замінить розробника”, як мінімум в якійсь осяжній перспективі, навіть якщо він настільки буде гарно писати код, що відпаде потреба в тому щоб це робила людина. Бо бути розробником - це значно більше, ніж просто писати код, особливо якщо ми говоримо про сеньйорів. Але є важливе “але” - трансформації IT-галузі під впливом AI настільки суттєві, що навіть найбільш топові технічно люди, однак такі, що не сприймають ці зміни - “сеньйори-старовіри” (назовемо їх так) просто будуть витіснені з професії, якщо не будуть активно змінюватися під впливом AI.
Отже по пунктах стосовно сеньйорів:
1. IT специфічна галузь з точки зору професійного зростання. Якщо у більшості інших галузей (за невеликими виключеннями, наприклад, спорт) фахівець з віком стає практично гарантовано більш досвідченим і “сеньйорнішим”, то тут технології розвиваються настільки швидко, що сеньйорність досягається не автоматом з роками, а за рахунок цілеспрямованих зусиль які мають бути щоденною рутиною: регулярним проходженням курсів, читанням статей, книжок, участю і підготовкою до виступів на мітапчиках/конференціях, створенням пет-проджектів і т.д. і т.п.
2. Будь-яка людина з часом змінюється, і навіть якщо хтось в минулому був занурений в роботу і розвиток 24/7, то зі зростанням “сеньйорності” і відповідно доходів, у таких людей з’являються сім’ї, діти, виникає бажання більше відпочивати і витрачати сеньйорні зарплати, що в свою чергу веде до скорочення часу для власного розвитку як фахівця. З віком ця гонитва за технічним прогресом починає набридати і люди часто переходять у менеджмент, де їх софтскілові навички та досвід взаємодії з людьми стають більш вирішальними. А технічні місця відповідно звільняються, а якщо хтось застрягає на посаді без розвитку - то під ризиком звільнення опиняється він сам.
3. Минулий багаж знань і навичок не завжди допомагає рухатися вперед, часто це заважає сприймати нове. Наприклад, люди зі значним досвідом ентерпрайз розробки у бекенді часто з великими складнощами сприймають підходи до фронтенду і їх треба буквально стримувати від ускладнення рішень зайвими складовими. Сьогодні часто досвідчені розробники все ще зверхньо сприймають код і рішення загалом створені за допомогою AI з упередженням “я зроблю краще”. Але вже зараз не кожен сеньйор напише код краще за AI, і зрозуміло що з кожним днем AI розвивається швидше за людину. Тому протиставляти себе AI замість того щоб активно його вивчати, впроваджувати і комбінувати власні сильні сторони з сильними сторонам AI - то завідомо програшна стратегія.
Зараз активно розганяється тема про те що джуни не потрібні, бо “їх замінить AI”. Хайпувати на всяких фобіях дуже зручно, але чому треба боятися більше сеньйорам, а не джунам я вам зараз розкажу. І сеньйори, до речі, вже почали потроху скромніше бути в своїх хотілках, кілька днів тому на DOU з’явилося цікаве дослідження https://dou.ua/forums/topic/54181/
Важливий дісклеймер - я взагалі не підтримую думку що “AI замінить розробника”, як мінімум в якійсь осяжній перспективі, навіть якщо він настільки буде гарно писати код, що відпаде потреба в тому щоб це робила людина. Бо бути розробником - це значно більше, ніж просто писати код, особливо якщо ми говоримо про сеньйорів. Але є важливе “але” - трансформації IT-галузі під впливом AI настільки суттєві, що навіть найбільш топові технічно люди, однак такі, що не сприймають ці зміни - “сеньйори-старовіри” (назовемо їх так) просто будуть витіснені з професії, якщо не будуть активно змінюватися під впливом AI.
Отже по пунктах стосовно сеньйорів:
1. IT специфічна галузь з точки зору професійного зростання. Якщо у більшості інших галузей (за невеликими виключеннями, наприклад, спорт) фахівець з віком стає практично гарантовано більш досвідченим і “сеньйорнішим”, то тут технології розвиваються настільки швидко, що сеньйорність досягається не автоматом з роками, а за рахунок цілеспрямованих зусиль які мають бути щоденною рутиною: регулярним проходженням курсів, читанням статей, книжок, участю і підготовкою до виступів на мітапчиках/конференціях, створенням пет-проджектів і т.д. і т.п.
2. Будь-яка людина з часом змінюється, і навіть якщо хтось в минулому був занурений в роботу і розвиток 24/7, то зі зростанням “сеньйорності” і відповідно доходів, у таких людей з’являються сім’ї, діти, виникає бажання більше відпочивати і витрачати сеньйорні зарплати, що в свою чергу веде до скорочення часу для власного розвитку як фахівця. З віком ця гонитва за технічним прогресом починає набридати і люди часто переходять у менеджмент, де їх софтскілові навички та досвід взаємодії з людьми стають більш вирішальними. А технічні місця відповідно звільняються, а якщо хтось застрягає на посаді без розвитку - то під ризиком звільнення опиняється він сам.
3. Минулий багаж знань і навичок не завжди допомагає рухатися вперед, часто це заважає сприймати нове. Наприклад, люди зі значним досвідом ентерпрайз розробки у бекенді часто з великими складнощами сприймають підходи до фронтенду і їх треба буквально стримувати від ускладнення рішень зайвими складовими. Сьогодні часто досвідчені розробники все ще зверхньо сприймають код і рішення загалом створені за допомогою AI з упередженням “я зроблю краще”. Але вже зараз не кожен сеньйор напише код краще за AI, і зрозуміло що з кожним днем AI розвивається швидше за людину. Тому протиставляти себе AI замість того щоб активно його вивчати, впроваджувати і комбінувати власні сильні сторони з сильними сторонам AI - то завідомо програшна стратегія.
DOU
Senior-розробники стали скромнішими в зарплатних очікуваннях
У новій розсилці Djinni видно, що сеньйори стали обережніші в зарплатних очікуваннях — медіана впала з $4500 до $4000. У мідлів і джунів усе стабільно та навіть трохи росте. Як думаєте, чому саме досвідчені розробники знижують запити? І як сьогодні адеква
June 13
І тепер переходимо до можливостей для джунів
1. В умовах коли відбувається трансформація галузі, то у людини, що не обтяжена якимось попередніми упередженнями яким чином щось потрібно робити, має достатньо вільного часу і мотивації до навчання набагато більше шансів випередити того хто спочиває на лаврах своєї “сеньйорності” і не готовий до кардинальних трансформацій у підходах до роботи.
2. Для бізнесу часто більш пріоритетно отримати швидке, хай і не досконале, але робоче рішення ніж якісне, зроблене по всім канонам софтверної інженерії, однак випущене занадто пізно і ще й в результаті задорого. Досвідченого розробника часто уповільнює потреба проробити всі деталі і пропрацювати всі ризики, але на практиці часто бізнес готовий їх прийняти, і якщо результат буде отриманий швидко, то досконалість технічного рішення для цього далеко не головне. І хоч ця думка мені самому не дуже подобається, але від реальності не втечеш - у джуна, що готовий швидко показати результат, більше шансів отримати погодження від бізнесу, ніж у сеньйора, який не поспішає, бо хоче пропрацювати всі деталі.
3. І звичайно, зарплатні очікування - сеньйори звикли заробляти багато, їм не було альтернативи - зробити якесь нормальне IT рішення без них раніше не було можливо в принципі. А вивчитися до сеньйорного рівня об’єктивно було не просто - для багатьох шлях з нуля до заслуженого тайтла сеньйора займав мінімум років 7-10 і з них останніх років 5 має бути комерційний досвід. Джуни отримували значно менше в першу чергу тому, що вони в принципі не здатні були видати пристойний результат і потребували стороннього допомоги.
4. Але вже зараз все сильно змінюється - в першу чергу стало набагато простіше вчитися. Раніше ти постійно впирався в якісь дрібниці і якщо в тебе поруч не було колеги чи ментора щоб допомогти, то був приречений на повільний пошук потрібної інформації в гуглі, по форумах і т.д. Зараз AI дозволяє вчитися набагато швидше і в процесі навчання ти все рідше впираєшся в непробивну стіну складного завдання.
5. І, нарешті, навіть якщо наш умовний сеньйор не є старовіром, а активно використовує AI сам, все одно він не може закривати нескінченну кількість тасок, бо їх треба формувати, чекати на роботу AI-інструментів, коригувати їх роботу, приймати її та щось виправляти/переробляти. Це все займає час і в ідеалі потребує таких же помічників-джунів, які були потрібні раніше в епоху “традиційної” розробки, коли код дводилося писати вручну.
Тому висновок дуже простий: якщо ви “правильний” джун чи намагаєтеся ним стати, а саме качаєте свої софтскіли, хардскіли та вдодачу до цього активно опановуєте AI, то у вас буде все добре з роботою. Але є важливе “але” - вчитися потрібно правильно, і якщо вам AI нагенерив коду, а ви поняття не маєте як він працює, то такий варіант не ок, треба в цьому розбиратися 🙂
1. В умовах коли відбувається трансформація галузі, то у людини, що не обтяжена якимось попередніми упередженнями яким чином щось потрібно робити, має достатньо вільного часу і мотивації до навчання набагато більше шансів випередити того хто спочиває на лаврах своєї “сеньйорності” і не готовий до кардинальних трансформацій у підходах до роботи.
2. Для бізнесу часто більш пріоритетно отримати швидке, хай і не досконале, але робоче рішення ніж якісне, зроблене по всім канонам софтверної інженерії, однак випущене занадто пізно і ще й в результаті задорого. Досвідченого розробника часто уповільнює потреба проробити всі деталі і пропрацювати всі ризики, але на практиці часто бізнес готовий їх прийняти, і якщо результат буде отриманий швидко, то досконалість технічного рішення для цього далеко не головне. І хоч ця думка мені самому не дуже подобається, але від реальності не втечеш - у джуна, що готовий швидко показати результат, більше шансів отримати погодження від бізнесу, ніж у сеньйора, який не поспішає, бо хоче пропрацювати всі деталі.
3. І звичайно, зарплатні очікування - сеньйори звикли заробляти багато, їм не було альтернативи - зробити якесь нормальне IT рішення без них раніше не було можливо в принципі. А вивчитися до сеньйорного рівня об’єктивно було не просто - для багатьох шлях з нуля до заслуженого тайтла сеньйора займав мінімум років 7-10 і з них останніх років 5 має бути комерційний досвід. Джуни отримували значно менше в першу чергу тому, що вони в принципі не здатні були видати пристойний результат і потребували стороннього допомоги.
4. Але вже зараз все сильно змінюється - в першу чергу стало набагато простіше вчитися. Раніше ти постійно впирався в якісь дрібниці і якщо в тебе поруч не було колеги чи ментора щоб допомогти, то був приречений на повільний пошук потрібної інформації в гуглі, по форумах і т.д. Зараз AI дозволяє вчитися набагато швидше і в процесі навчання ти все рідше впираєшся в непробивну стіну складного завдання.
5. І, нарешті, навіть якщо наш умовний сеньйор не є старовіром, а активно використовує AI сам, все одно він не може закривати нескінченну кількість тасок, бо їх треба формувати, чекати на роботу AI-інструментів, коригувати їх роботу, приймати її та щось виправляти/переробляти. Це все займає час і в ідеалі потребує таких же помічників-джунів, які були потрібні раніше в епоху “традиційної” розробки, коли код дводилося писати вручну.
Тому висновок дуже простий: якщо ви “правильний” джун чи намагаєтеся ним стати, а саме качаєте свої софтскіли, хардскіли та вдодачу до цього активно опановуєте AI, то у вас буде все добре з роботою. Але є важливе “але” - вчитися потрібно правильно, і якщо вам AI нагенерив коду, а ви поняття не маєте як він працює, то такий варіант не ок, треба в цьому розбиратися 🙂
June 13
Хто хоче наживо поспілкуватися завтра у Львові, приходьте, буде цікава благодійна подія, я один зі спікерів. Будемо говорити про таски в джирі, я звичайно розкажу про те як на це все впливає AI :)
June 13
Forwarded from Дивовижний світ веброзробки
Львове! Зустрінемось? ;)
Запрошую вас на благодійний мітап "Від ʼхотілкиʼ до задачі: звідки беруться таски у вашій джирі"!
Як "забаганка" стейкхолдера перетворюється на чітко поставлену задачу в Jira? Цей процес не такий простий, як здається — і кожен фахівець бачить його по-своєму.
Разом з Kaizen Hub ми запросили Мар'яну Бандровську — ex-Head of BA в Sombra, Романа Марінського — Core Quality CoE expert в Intellias та В'ячеслава Колдовського — Competence Manager в SoftServe, аби обговорити весь шлях від першої ідеї до готового таску. Кожен розповість про свою роль у цьому процесі:
— Як правильно "розпакувати" вимогу та зробити її зрозумілою для всіх
— Що потрібно врахувати для якісного тестування
— Яка технічна інформація критично важлива для реалізації
Обговоримо типові проблеми на кожному етапі трансформації вимог:
— Як різні ролі бачать одну й ту саму задачу
— Які питання треба ставити, щоб уникнути недопорозумінь
— Практичні інструменти для ефективної комунікації між командами
Після дискусії — сесія Q&A, де ви зможете поставити свої запитання панелістам та отримати поради для конкретних ситуацій.
Ну а я цю подію модеруватиму.
Коли: 14 червня, 13:00
Де: Гастропаб "Довгі бурхливі оплески", Львів, вул. Січових Стрільців 3
Вартість: благодійний внесок 500 грн
Для кого: BA, PM, QA, розробники, тімліди — всі, хто працює з вимогами та управлінням завданнями
🚀 КВИТКИ ПРИДБАТИ ТУТ
Усі виручені кошти підуть на потреби ЗСУ!
Ну то як, зустрінемось?
Запрошую вас на благодійний мітап "Від ʼхотілкиʼ до задачі: звідки беруться таски у вашій джирі"!
Як "забаганка" стейкхолдера перетворюється на чітко поставлену задачу в Jira? Цей процес не такий простий, як здається — і кожен фахівець бачить його по-своєму.
Разом з Kaizen Hub ми запросили Мар'яну Бандровську — ex-Head of BA в Sombra, Романа Марінського — Core Quality CoE expert в Intellias та В'ячеслава Колдовського — Competence Manager в SoftServe, аби обговорити весь шлях від першої ідеї до готового таску. Кожен розповість про свою роль у цьому процесі:
— Як правильно "розпакувати" вимогу та зробити її зрозумілою для всіх
— Що потрібно врахувати для якісного тестування
— Яка технічна інформація критично важлива для реалізації
Обговоримо типові проблеми на кожному етапі трансформації вимог:
— Як різні ролі бачать одну й ту саму задачу
— Які питання треба ставити, щоб уникнути недопорозумінь
— Практичні інструменти для ефективної комунікації між командами
Після дискусії — сесія Q&A, де ви зможете поставити свої запитання панелістам та отримати поради для конкретних ситуацій.
Ну а я цю подію модеруватиму.
Коли: 14 червня, 13:00
Де: Гастропаб "Довгі бурхливі оплески", Львів, вул. Січових Стрільців 3
Вартість: благодійний внесок 500 грн
Для кого: BA, PM, QA, розробники, тімліди — всі, хто працює з вимогами та управлінням завданнями
🚀 КВИТКИ ПРИДБАТИ ТУТ
Усі виручені кошти підуть на потреби ЗСУ!
Ну то як, зустрінемось?
June 13
Відкриті Очі
В твіттері несеться черговий шакалячий експрес за донати, що йшли не по призначенню. То думаю пора би всім розуміти, що донатити варто лише туди, де є звітність і все можна перевірити.
В SoftServe, де я працюю, є власний благодійний фонд “Відкриті очі”, і він робить величезну роботу, а головне - все відкрито і перевіряється.
Один з проєктів фонду - передача на фронт понад 320 машин швидкої допомоги.
Але ці швидкі самі потребують захисту, адже вони часто стають ціллю для ворога. Тому зараз разом з Океан Ельзи фонд збирає 15 мільйонів гривень на 50 комплектів РЕБів, які встановлять на швидкі, що вже рятують життя на фронті. РЕБ дезорієнтує дрон – і машина уникає удару. Він на 90%+ знижує шанс на ураження дроном на радіокеруванні. Це не тільки збережена машина швидкої, яка дуже цінна на фронті, але й збережені життя екіпажу і поранених.
Тому пропоную підтримати цей збір донатом на сайті, а ще можна відвідати концерти Океану Ельзи у Львові.
Посилання на збір: https://openeyesfund.com/ua/projects/lifewaves-powered-by-okean-elzy
В твіттері несеться черговий шакалячий експрес за донати, що йшли не по призначенню. То думаю пора би всім розуміти, що донатити варто лише туди, де є звітність і все можна перевірити.
В SoftServe, де я працюю, є власний благодійний фонд “Відкриті очі”, і він робить величезну роботу, а головне - все відкрито і перевіряється.
Один з проєктів фонду - передача на фронт понад 320 машин швидкої допомоги.
Але ці швидкі самі потребують захисту, адже вони часто стають ціллю для ворога. Тому зараз разом з Океан Ельзи фонд збирає 15 мільйонів гривень на 50 комплектів РЕБів, які встановлять на швидкі, що вже рятують життя на фронті. РЕБ дезорієнтує дрон – і машина уникає удару. Він на 90%+ знижує шанс на ураження дроном на радіокеруванні. Це не тільки збережена машина швидкої, яка дуже цінна на фронті, але й збережені життя екіпажу і поранених.
Тому пропоную підтримати цей збір донатом на сайті, а ще можна відвідати концерти Океану Ельзи у Львові.
Посилання на збір: https://openeyesfund.com/ua/projects/lifewaves-powered-by-okean-elzy
Openeyesfund
Life Waves. Powered by Okean Elzy
Life Waves — це відповідь на загрозу, проект, у якому кожна передана система — як хвиля спротиву, що піднімається проти сигналу, здатного забрати життя. Ці технології для захисту м...
June 18
Невеликий звіт про зустріч в суботу на тему “Від ʼхотілкиʼ до задачі”
Дуже класний формат - неформальна розмова в барі, без онлайн-трансляцій і запису, то говорити можна у дуже вільному форматі, чим ми і скористалися на повну. :)
Аудиторія зібралася досить мачурна - розробники, BA, QA, ліди і т.д.
Хоча тема була досить прозаїчна - формулювання задач і відповідно робота з вимогами, але питань було купа, видно що для всіх актуально.
Своє власне бачення по вимогам викладу наступним постом.
Дякую всім, хто прийшов і Сергію Бабічу за запрошення, сподіваюся далі буде :)
P.S. На фотці я з Артемом, він фронтендщик працює в SoftServe, починав на курсі з основ фронтенду, який я там викладаю, завжди радий бачити своїх випускників, тут недавно порахували, що їх вже більше чотирьох тисяч за весь час існування курсу :)
Дуже класний формат - неформальна розмова в барі, без онлайн-трансляцій і запису, то говорити можна у дуже вільному форматі, чим ми і скористалися на повну. :)
Аудиторія зібралася досить мачурна - розробники, BA, QA, ліди і т.д.
Хоча тема була досить прозаїчна - формулювання задач і відповідно робота з вимогами, але питань було купа, видно що для всіх актуально.
Своє власне бачення по вимогам викладу наступним постом.
Дякую всім, хто прийшов і Сергію Бабічу за запрошення, сподіваюся далі буде :)
P.S. На фотці я з Артемом, він фронтендщик працює в SoftServe, починав на курсі з основ фронтенду, який я там викладаю, завжди радий бачити своїх випускників, тут недавно порахували, що їх вже більше чотирьох тисяч за весь час існування курсу :)
June 18
Отже, про “Хотілки і задачі”
Загалом, невміння працювати з вимогами - то ознака незрілого розробника, навіть якщо у нього “накапало” не один рік досвіду, але завжди говорю, що досвід в IT - то не про роки.
Коли проводжу якісь інтерв’ю/евали, то часто даю однакові завдання що джунам, що сеньйорам, і ще до того як людина почне писати код вже буде зрозуміло її технічний рівень.
Справжній сеньйор ніколи не почне писати код, доки детально не розбереться з вимогами, все не зафіксує в письмовій формі і не погодить з замовником. Менш досвідчені люди зазвичай поспішають писати код, але потім стикаються з проблемами, коли зроблено не те що треба, не так як треба і т.д.
Між тим щоб просто “якось сформувати вимоги” і “коректно сформувати вимоги” лежить ціла прірва. Не можна покладатися на те що вам просто видадуть якісь перфектні вимоги, які треба лише сконвертувати в код. Найбільш ймовірно, щоб вони були перфектними, треба самим докласти зусиль в їх уточнення і формулювання і це абсолютно нормально, не покладайтеся що це все має зробити лише BA, спокійно додавайте/правте все що вважаєте за потрібним.
Окремо слід сказати про функціональні/нефункціональні вимоги. Зазвичай максимум уваги йде на функціональні, які відповідають на питання “що треба зробити”, але від нефункціональних, які відповідають на питання “як має працювати” теж багато залежить. І щоб не було потім зайвих питань, наприклад, чому працює повільно, то відповідь треба прописати у якості конкретного числа у нефункціональних вимогах.
І нарешті критерії прийому роботи - ніколи не слід лінуватися зафіксувати чітко що буде вважатися виконаною роботою.
Але чи не найважливіше - це погодження вимог. Бо є безліч причин, чому не кожну фічу треба робити, що особливо актуально у великих проєктах з купою стейкхолдерів. Я розказував про RACI-матрицю - вона завжди повинна бути, навіть просто у вигляді уявного списку в голові, бо іноді розробнику може дістатися не за те що не зробив, а за те що зробив щось, що не погодив з кимось важливим.
Загалом, невміння працювати з вимогами - то ознака незрілого розробника, навіть якщо у нього “накапало” не один рік досвіду, але завжди говорю, що досвід в IT - то не про роки.
Коли проводжу якісь інтерв’ю/евали, то часто даю однакові завдання що джунам, що сеньйорам, і ще до того як людина почне писати код вже буде зрозуміло її технічний рівень.
Справжній сеньйор ніколи не почне писати код, доки детально не розбереться з вимогами, все не зафіксує в письмовій формі і не погодить з замовником. Менш досвідчені люди зазвичай поспішають писати код, але потім стикаються з проблемами, коли зроблено не те що треба, не так як треба і т.д.
Між тим щоб просто “якось сформувати вимоги” і “коректно сформувати вимоги” лежить ціла прірва. Не можна покладатися на те що вам просто видадуть якісь перфектні вимоги, які треба лише сконвертувати в код. Найбільш ймовірно, щоб вони були перфектними, треба самим докласти зусиль в їх уточнення і формулювання і це абсолютно нормально, не покладайтеся що це все має зробити лише BA, спокійно додавайте/правте все що вважаєте за потрібним.
Окремо слід сказати про функціональні/нефункціональні вимоги. Зазвичай максимум уваги йде на функціональні, які відповідають на питання “що треба зробити”, але від нефункціональних, які відповідають на питання “як має працювати” теж багато залежить. І щоб не було потім зайвих питань, наприклад, чому працює повільно, то відповідь треба прописати у якості конкретного числа у нефункціональних вимогах.
І нарешті критерії прийому роботи - ніколи не слід лінуватися зафіксувати чітко що буде вважатися виконаною роботою.
Але чи не найважливіше - це погодження вимог. Бо є безліч причин, чому не кожну фічу треба робити, що особливо актуально у великих проєктах з купою стейкхолдерів. Я розказував про RACI-матрицю - вона завжди повинна бути, навіть просто у вигляді уявного списку в голові, бо іноді розробнику може дістатися не за те що не зробив, а за те що зробив щось, що не погодив з кимось важливим.
June 18
DOU як топовий ресурс для айтівців розкрутився в першу чергу за рахунок зарплатних опитувань і аналітики по їх результатам.
Зараз проводиться чергове опитування. Хто вже працює в IT - не забудьте заповнити, там не лише про зарплати, а портрет айтівця загалом.
Зараз проводиться чергове опитування. Хто вже працює в IT - не забудьте заповнити, там не лише про зарплати, а портрет айтівця загалом.
DOU
Зарплатне опитування DOU і портрет айтівця. Долучайтеся!
Запускаємо літнє зарплатне опитування DOU. На анкету знадобиться не більше як 10 хв. Чекаємо всіх айтівців - тих, хто живе в Україні та за кордоном. І спеціалістів усіх напрямів: розробників, QA, менеджерів, DevOps, маркетологів, сапорт, сейлз, HR тощо. Результати…
June 20
Знову на тему джунів і ШІ
Цікавий опитувальник від ДОУ, шкода що з цим питанням не прийшли до мене, бо розказати є багато що, тим більше що нещодавно на цю тему писав :)
З часом буде видно, але на моє переконання — мова не про «вбивання 30-40% джунівських вакансій», а про значну трансформацію галузі, яку більшість її учасників просто ще не розуміють, тому для них воно виглядає як те що джунів треба буде менше. Однак в реальності це більше схоже на зміну характера роботи, який стосуєтсья всіх — і джунів, і мідлів, і сеньйорів.
Якщо коротко, то всі під загрозою і водночас для всіх відкриваються нові можливості.
Стосовно фронтенду, то це в першу чергу значне зростання продуктивності команд за рахунок того що тепер левову частку «ручної» рутини — верстку, дрібні анімації, юніт-тести, генерування типового коду — команда перекладає на ШІ-інструменти. Те, що раніше з’їдало день-два роботи джуна, сьогодні робиться за 15 — 20 хвилин правильно сформульованим промптом.
Але це не означає, що цю роботу не повинні робити ті розробники, які раніше називалися джунами. Чи ми всерйоз важаємо що для цього треба цілого сеньйора з сеньйорними зарплатами?
Звісно що ні, раніше бізнес тримав сеньйорів за великі гроші просто тому що джун в принципі не міг зробити щось більш-менш нормальне під бізнес вимоги, але тепер все змінилося і «правильно навчений» джун здатен видавати хоча б не сеньйорну роботу, але мідлову точно. Залишається питання оптимальності по швидкості, вразливостей, і т.д. і т.п., і це саме те місце де можна підключити більш досвідчених розробників, витрачати ресурси яких на «джуновську роботу» не дуже розумно.
Тому копаємо глибше, ми зараз тільки зазираємо у ту кролячу нору, а вся її глибина нас ще чекає попереду :)
Цікавий опитувальник від ДОУ, шкода що з цим питанням не прийшли до мене, бо розказати є багато що, тим більше що нещодавно на цю тему писав :)
З часом буде видно, але на моє переконання — мова не про «вбивання 30-40% джунівських вакансій», а про значну трансформацію галузі, яку більшість її учасників просто ще не розуміють, тому для них воно виглядає як те що джунів треба буде менше. Однак в реальності це більше схоже на зміну характера роботи, який стосуєтсья всіх — і джунів, і мідлів, і сеньйорів.
Якщо коротко, то всі під загрозою і водночас для всіх відкриваються нові можливості.
Стосовно фронтенду, то це в першу чергу значне зростання продуктивності команд за рахунок того що тепер левову частку «ручної» рутини — верстку, дрібні анімації, юніт-тести, генерування типового коду — команда перекладає на ШІ-інструменти. Те, що раніше з’їдало день-два роботи джуна, сьогодні робиться за 15 — 20 хвилин правильно сформульованим промптом.
Але це не означає, що цю роботу не повинні робити ті розробники, які раніше називалися джунами. Чи ми всерйоз важаємо що для цього треба цілого сеньйора з сеньйорними зарплатами?
Звісно що ні, раніше бізнес тримав сеньйорів за великі гроші просто тому що джун в принципі не міг зробити щось більш-менш нормальне під бізнес вимоги, але тепер все змінилося і «правильно навчений» джун здатен видавати хоча б не сеньйорну роботу, але мідлову точно. Залишається питання оптимальності по швидкості, вразливостей, і т.д. і т.п., і це саме те місце де можна підключити більш досвідчених розробників, витрачати ресурси яких на «джуновську роботу» не дуже розумно.
Тому копаємо глибше, ми зараз тільки зазираємо у ту кролячу нору, а вся її глибина нас ще чекає попереду :)
DOU
«ШІ вб’є 30–40% джунівських вакансій». Як штучний інтелект змінює роботу початківців у фронтенді
Що ШІ може робити замість джуна у фронтенді? Чи варто розробникам-початківцям активно користуватися ШІ в роботі та як навчитися писати якісні промпти для цього? Читайте у новому випуску рубрики "ШІ vs Джуніори".
June 24