Пост про те, що, на мою думку, має виконувати розробник коли він Senior. Я працюю в продуктовій компанії і в нас інженер приймає участь в розробці фічі від обговорення продуктового рішення до реалізації в продакшені і аналізі результатів. В інших компаніях скоуп може бути менший, щось можливо відрізняється, але основа буде +- така сама.

Навіщо це?

Я вірю що кожен розробник має розуміти що він робить і як це впливає на бізнес. Недостатньо написати код. Розуміння повного флоу допомагає приймати рішення. Ще кажуть що це “продуктове мислення”.

То ж розглянемо наступні етапи:

Підготовка до розробки

1. На етапі коли продакт оунер презентує нову ідею необхідно зрозуміти, а що треба робити. Визначити питання які не розкриті, проговорити edge cases, негативні сценарії.
2. Визначити технічний стек. Якщо це нова фіча/cервіс - технології, бібліотеки, мова програмування.
3. Створити архітектуру фічі, розробити Тех дизайн документ.
4. Проговорити з QA інженером тест план, тест кейси. Визначити на що звернути увагу, edge cases, auto tests coverage.
5. Проговорити з бізнес аналітиком які метрики додати (будемо використовувати) для того, що б можна було провести A/B тестування
6. Оцінити задачі (в днях, сторіпоінтах, сферичних конях) та оцінити ризики. Бути готовим захендлити ризики.
7. Запланувати роботу в команді а також (якщо необхідно) роботу на сусідніх командах (приклад: бекенд має зробити API для фронтенду)

Кодінг

1. Написати код
2. Написати тести

Підготовка до релізу

1. Обговорити з продуктовою командою як релізити фічу (аудиторія A/B тесту)

Реліз

1. Реліз в продакшен
2. Моніторинг фічі в продакшені. Zero-error policy
3. Слідкувати за issues and fix bugs
4. Допомогти аналітику проаналізувати результати A/B тесту. Якщо є падіння по метрикам в новому функціоналі, знайти проблеми і почати нову ітерацію A/B тесту. Падіння метрик - це очікуваний закономірний процес змін в процесі A/B тесту.

Cleanup

1. Видалити залишки A/B тесту з коду
2. Перевірити задачі які залишились (leftovers) та приорітизувати їх

Takeaways:

1. Кожен інженер як individual contributor має вміти захендлити задачу від початку до кінця. ТА ми не знецінюємо командну роботу! Ми не відміняємо PR review, командну допомогу, сінки і парне програмування. Ідея в тому, що головний “водій” (рушійний механізм) який штовхає фічу вперед - розробник.
2. Не всі етапи релевантні до кожної задачі
3. Кожна задача має свій рівень складності. Це може бути coding complexity, може бути складність у релізі (багато міжкомандних звʼязків). То ж загальна складність задачі - це щось середнє між цими рівнями складності. Важливо це розуміти для тімліда при поділі задач.
4. Якщо ви працюєте в англомовному середовищі, англійська мова стає найважливішою “мовою програмування” (ви використовуєте JS, Python, Kotlin що завгодно тільки на “Кодінг” етапі, в той час інші етапи потребують комунікацій з іншими командами чи продакт людьми)

Чи думаєте ви що це забагато ? 🙂