End-to-end ответственность: что отличает сеньора от «перекладывателя кода»

– Мы тут тааакую фичу запилили за неделю, навайбкодили! – О, крутяк, а где можно потыкать? – Ну, эээ, понимаешь, оно ещё там на деве, короче, ты запроси доступ…

Это практически дословный (и довольно свежий) диалог из моей практики. Не сказать, что LLM-ки в разработке привнесли в этом плане что-то новое – проблемы с критериями готовности я встречал всегда. Похоже, пора поговорить о том, что означает «задача закончена» и где на самом деле находится точка «запилили фичу».

⭐️ Когда работа над фичей считается завершённой?

Короткий ответ – никогда. Если подумать чуть дальше рамок «написать код», то оказывается, что фича – это ещё и тестирование, раскатка, дальнейшее сопровождение и даже вывод из эксплуатации. Любая фича в любом продукте – это живая сущность, которая постоянно изменяется и эволюционирует.

Но такой ответ вряд ли удовлетворит среднего разработчика (и даже тимлида), которым нужен некоторый критерий завершённости. Я для себя сформулировал его так:

Фича закончена = фича выкачена в прод на всех клиентов и активно используется

Последнее невозможно повесить только на разработку. Бывают ситуации, когда фичу «высосали из пальца», и тогда ей никто толком пользоваться не будет. Для разработки я этот критерий применяю скорее как маркер стабильности: если фичей успешно пользуются реальные пользователи, значит, с ней всё в порядке.

⭐️ За что ещё отвечает разработчик, помимо написания кода

Конечная задача разработки – поставлять ценность для бизнеса в виде потока фич. Фича «на деве», «на стейджинге» и даже «сделана, но скрыта под фича-флагом» = фича не работающая и не приносящая пользы. Следовательно, есть целый пласт работ помимо написания кода, который нужно делать для успешной поставки и который обычно все дружно игнорируют, пытаясь в очередной раз «ускорить разработку LLM-ками».

Вот частая история: фича требует изменений в конфигах. Помимо написания кода, разработчик должен ещё и предусмотреть необходимые изменения в конфигах на всех стендах по мере прокатки новой фичи. Возможно, в работе используются некоторые шаблоны конфигурации, которые теперь нужно поправить. А ещё желательно самому проконтролировать релиз этой фичи, чтобы на проде ничего не развалилось. И про метрики/алертинг не забыть.

Звучит немного сложнее, чем просто «навайбкодили фичу», не так ли? А это я ещё намеренно опустил пострелизную работу с фичей (за которую больше отвечают продакты). Тем не менее, такая end-to-end ответственность в моей картине мира является обязательным атрибутом senior-разработчика. И она намного ценнее, чем знание очередного модного фреймворка.