Когда берешься за проект, помни!

Люди, которые ставят задачи, делятся на четыре категории:

  1. которые документируют технические задания и описывают требования, по которым можно разрабатывать и поддерживать продукт;
  2. которые умеют документировать технические задания, но не хотят;
  3. которые хотят описать требования, но не умеют;
  4. которые не хотят и не умеют;

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

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

Третья категория опасна для разработчиков и фрилансеров. Вы, как программист, имеете на руках техническое задание, работаете по нему и постоянно сталкиваетесь с неточностями, противоречиями, отсутствием чувства целостности, изменениями в спецификации за неделю до релиза и многими другими вещами, которые негативно скажутся на качестве. Плохо, если спецификация опирается на еще несуществующий компонент, у которого в свою очередь нет спецификации, или на разработанный компонент без документации. Но тут есть путь к спасению: а) отправить людей на курсы повышения квалификации; б) нанять профессионалов с доказанным опытом; в) передать описание технического задания человеку, у которого есть видение, при том условии, что он имеет опыт в написании ТЗ, иначе есть риск перейти в категорию уровнем ниже. В больших компаниях есть целые отделы, которые занимаются описанием требований. Но они не утруждают себя заглянуть достаточно глубоко в проект, над которым они работают, из-за невовлеченности и  неинтегрированности сотрудника, который описывает требования, в команду разработчиков, незнание или непонимание матчасти, предметной области.

Четвертая категория самая опасная. Если вы приходите в компанию и видите, что в ней написано 100500 строк кода, при этом ноль целых ноль десятых описывающей документации, то это звоночек, чтобы бежать оттуда сверкая пятками. Это путь в тупик. Однако, если кода не так много, то можно попытаться перевести команду в третью категорию итальянской забастовкой: четко следовать должностной инструкции и не делать ни одной новой фичи без спецификации. Но это может сработать только если к вам прислушиваются, и вам небезразлична идея. Впрочем, вывод о том, что работаешь с непрофессионалами, людьми, которые, скорее всего, в этом бизнесе пару дней, это также звоночек о необходимости увольнения. Хотя, кому-то это нравится.

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

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

 

Запись опубликована в рубрике Uncategorized с метками . Добавьте в закладки постоянную ссылку.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *