Это не работа для программиста

Недавно пришёл интересный вопрос, или даже скорее жалоба. Я приведу его в урезанном виде, так как там было много текста.

У нас такие процессы, что разработчик сам пишет документацию к тому, что заимплементил. Не документацию коду, а именно документацию к функционалу, пользовательскому интерфейсу и т.д. Я вообще против такого, потому что я не понимаю, почему на девелоперов сваливают работу менеджеров, продукт-оунеров и прочих бесполезных людей, у которых полно времени, но они все еще сами не могут заниматься написанием документации. Мной неоднократно и аргументированно говорилось всем этим людям об идиотизме такого процесса, что вообще-то сначала составляются требования, потом происходит разработка и т.д., но меня не слушали. Якобы потому что у нас "девелопер" должен быть "активным", то есть, если он предложит какое-то изменение или фичу к юзабилити, он должен сам писать документацию, потому что "только он знает, как он реализовал", хотя в документации НЕТ деталей, касающихся непосредственно кода! Юзабилити и прочие предложения по улучшению фич - это НЕ работа девелопера. Они просто хотят побольше скинуть работы на нас, обезьянок.

Такой вот крик души. По сути тут есть несколько тезисов, о которых бы я хотел порассуждать.

Первый, неявно выраженный: бесполезность PM и PO.

К сожалению автор вопроса не указал ни каких подробностей о себе и своём опыте, так что мне приходится лишь предполагать. Скорее всего, ты находишься в начале своей карьеры, ну может года три-четыре и отработал. Пожалуй в таком случае ещё могли сохраниться мысли о супер важности программиста, и бесполезности остальных членов команды. Увы, это не так.

Любой бизнес и любой проект — это результат совместной работы всей команды. Начиная от техписателей и до финансового и операционного директоров. Инженеры играют важную роль в имплементации чужих идей, но должность эта по-сути заменяемая. Сегодня код пишешь ты, завтра на твоё место наймут нового разработчика, а ты уйдёшь в другую компанию, заменять инженера, который нашёл место теплее.

Более того, код системы — не такая уж и большая ценность. Конечно, если ты пишешь какую-нибудь десктопную утилитку, то украв её код, любой может собрать её дома и запускать бесплатно, но в серьёзных системах код — это лишь мизерная часть бизнеса. Сам подумай, сколько в мире коммерческих систем с открытым кодом? Это не мешает им зарабатывать деньги, да?

Увы, но важнее данные, контракты с клиентами, бренд, авторитет и экспертиза компании. От сюда и пара выводов:

качество кода важно разработчикам, но не бизнесу
документация к коду важна разработчикам, но не бизнесу

По-этому, не удивительно, что от тебя не требуют документацию к коду, но требуют документацию к фичам. Попросту она — важна для бизнеса. Это то, как система работает и то, как ей нужно пользоваться. А что у тебя там под капотом никого не ебет, прости.

Что касается твоих идей о том, что сначала должна писаться спецификация, а потом уже реализация, то тут ты прав, конечно. Такое бывает, и это, пожалуй самое простое для инженера — взять чью-то идею, и спокойно написать к ней код. Собственно, любой джуниор и мидлл должен быть к этому готов.

Написание спецификаций - это не работа девелопера

Тут ты прав, это не для простого девелопера.

Однако, старший/ведущий инженер — это именно тот, кто должен брать требования заказчика/клиента и превращать их в спецификации к фиче. Это тот, кто будет планировать работу, тот кто оценивает риски, сроки и возможность построить ту или иную фичу. То есть, это как раз-таки и есть задача инженера.

Чем выше ты по карьерной лестнице, тем больше в твоей работе будет митингов, дизайна и документации, и тем меньше кода, так уж всё это устроено.

Такой вот непопулярный момент: программист — пишет программу, инженер превращает хотелки в работающую систему.

То что происходит у тебя в проекте очень похоже на несоответствие ожиданий с двух сторон. Компания ожидает, что у них работают инженеры, которые могут помочь бизнесу, а по факту таких людей у вас нет. Я не знаю, почему их не наймут, но видимо тому есть причины. А раз таких людей нет, то их нужно вырастить внутри компании, раздав всем подобные задач.

Что делать?

Я конечно, написал там выше, что ты не совсем прав, но что-то с этим делать необходимо. В конце-концов нервы дороже.

Для начала нужно попытаться осознать, что работа девелопера — это не только код, а работа менеджера — это не только митинги. Хорошо бы понять, а чем собственно они занимаются. Ничего не мешает тебе поговорить, расспросить их об их задачах и обязанностях. Можно в формате 1-on-1 митинга, а можно просто за пивом в пятницу вечером.

Далее, нужно поменять подход к обсуждению процессов. Упирая на то, что это не задачи для программиста, ты лишь показываешь себя каким-то избалованным и инфантильным подростком, прости. Возможно стоит донести до менеджеров, что в команде есть несколько хороших и толковых исполнителей, которым тяжело писать документацию и заниматься анализом системы. И в той же команде наверняка есть люди, которые хорошо делают эту часть работы, но которым не так интересно писать код, и возможно стоит чуть изменить структуру команды.

Те кто могут мыслить глобально, на уровне фичей, а не на уровне кода, тех можно поставить на позиции старших разработчиков, технических лидов (да похуй, как вы их там назовёте, суть не изменится), а чисто ручную работу по имплементации этих спецификаций оставить тем, кто делает это хорошо и с удовольствием.

Таким образом из плоской структуры инженерной команды вы перейдёте к более классическому варианту с бизнес-ориентированным ядром старших инженеров, способных переводить запросы PO и PM на понятный девелоперам язык спецификаций и архитектуры.

Я не знаю специфику бизнеса в котором ты работаешь, возможно это заказная разработка, а не внутренний продукт. В таком случае, логично, что артефакт, который поставляется заказчику, это не только работающая система, но и документация по её поведению. Однако, если ты работаешь над внутреннем продуктом, то... может стоит поставить вопрос о целесообразности такой подробной документации экранов и фич?

Раз уж ты не видишь ценности в таких документах, то может её и нет на самом-то деле. Одно дело, когда на основе этих документов готовятся мануалы для пользователей, или они отдаются команде технических писателей для составления инструкций и тренингов для операторов, работающих с вашей системой. А другое дело, когда эти доки висят мёртвым грузом в вашем интранете на какой-то wiki-страничке, которую никто никогда не смотрит. Это тоже вопрос, который можно поднять на каком-нибудь митинге и обсудить.

Может получиться так, что ничего ты изменить не сможешь, тогда выхода у тебя два.

Первый — расслабиться и получать ценный опыт написания спецификаций и анализа требований. Когда-нибудь, когда ты займёшь более высокую должность, где тебе придётся составлять подобные требования для подчиненных тебе разработчиков, ты оценишь важность этого навыка. Лучше учиться сейчас, когда на тебе меньше ответственности.

Второй — найти новую работу в более крупной компании, где ты сможешь занять место, которое тебе лучше подходит. Нет ничего плохого в том, что тебе больше нравится писать код, а не заниматься UX-анализом и спецификациями. Это разные поля деятельности, и никто не должен хорошо делать всё. Это нормально.

Посты на эти и другие темы публикую в канале: https://t.me/your_soft_skillzz

и твиттере https://twitter.com/soft_skillzz

Напоминаю, что мне можно задать вопрос или предложить свою тему для нового поста через форму обратной связи: https://goo.gl/forms/1G2206MfVzfoowHf2

Подписывайтесь и рассказывайте друзьям.

МS.