Folder image via Shutterstock.[Об авторе: Наталия Ништа — профессиональный разработчик, воплощенный в образе миловидной барышни. Считает свою работу увлекательным хобби, делая акцент на командную игру: «Если вы меня спросите, что такое проект, — то я отвечу вам, что это люди, которые его делают. Я убеждена, что личность всегда оставляет свой отпечаток в любых вещах, которые создаёт».]
Каждый раз, когда я слышу фразу «нашему проекту столько-то (4, 5, 7...) лет», хочется спросить: «есть ли у вас документация и в каком она состоянии?».
Как показывает практика, самые типичные ситуации такие:
— Документации нет. Или руководству об этом ничего не известно.
— Документация есть. Однако руководство о ней также имеет смутное представление. Очень часто такая документация не соответствует действительности, она неполная, а местами даже лживая.
— Документация есть, но позже оказывается, что она сугубо техническая.
Хотите выделиться на собеседовании? Спросите, нет ли на проекте документов, описывающих бизнес-процессы (скорее всего, нет), есть ли в команде аналитик или проджект-менеджер. А если документация таки есть, то кто занимается её ведением.
Зачем и когда это нужно
Разумеется, можно делать записи для чего угодно. Но стоит ли тратить на это драгоценное время? А если стоит, то в каких случаях?
Руководствуясь здравым смыслом, я выделяю два наиболее важных для разработчика вида документации:
— описания бизнес-процессовпроекта (Business Process Documentation) — по моему глубокому убеждению, самые нужные из всех возможных. Критически важны для понимания «а что здесь вообще происходит».
— описания особенностей и тонкостей технической реализации (Technical Documentation). Критически важны для общедоступных API и проектов; здесь качество работы определяет размер будущего community проекта. Информацию по внутреннему коду стоит фиксировать только в случае крайней необходимости. Об этом рекомендую почитать в книге господина Роберта Мартина«Чистый код».
Конечно же, существует масса прочих видов документации (например, пользовательская), но это уже совсем другая история. Целью данной статьи является осветить аспекты темы, важные непосредственно для разработчика.
Итак, в каких же случаях стоит потрудиться и что должно к этому мотивировать.
1. Пишите для себя.Даже если на проекте задействовано минимальное количество людей и все «и так знают», что, и где как работает, и какие процессы подлежат автоматизации — никогда не бывает лишним оставить «пару строк» об изменившихся или новых бизнес-процессах. Потому что даже если никто, кроме вас, не будет работать с этим продуктом, то через полгода вы сами уже будете другими людьми. И занимаясь написанием документации сейчас, на самом деле вы пишете ее для себя будущего.
2. Для обучения других людей.Пользу описаний бизнес-процессов для вновь прибывших сотрудников трудно переоценить. Стоит напомнить, что огромные талмуды никто не любит, поэтому если вам выпала честь заниматься священным делом поддержки документации, всегда помните о людях, которые будут читать ваши записи.
Информация о проекте должна быть общедоступной для сотрудников организации, а особенно для проектной команды. Если у кого-то из участников возникнут вопросы по предметной области, он не будет бегать за коллегами, а зайдет в соответствующий раздел документации. Разумеется, информация должна быть хорошо структурирована и не причинять адской боли в попытках что-то в ней найти.
3. Условная заменяемость.Пожалуй, это самый неочевидный и трудный для понимания пункт, в равной степени нужный компании, проекту, команде и непосредственно разработчику. Мерой осознания этого механизма вполне можно измерять свой профессионализм. Поэтому остановимся на нём подробно.
Написание документации — это процесс отчуждения интеллектуальной собственности участников проектной команды. Если такой человек покинет проект, при этом не зафиксировав свои наработки, — фактически он унесёт с собой интеллектуальную собственность компании, и в этот момент ничего уже поделать нельзя. Остаётся только надеяться, что руководство позволило этому человеку цивилизованно покинуть проект, и он изредка сможет давать свои консультации, если будет располагать достаточным временем и желанием.
У меня вызывает искреннее недоумение, почему при столь очевидной важности интеллектуальной собственности руководство очень часто понятия не имеет, что написано в документации, если она вообще есть. Нежелание вникать в особенности функционирования проекта (и бизнеса в IT-отрасли вообще) порождает соответствующее отношение со стороны разработчиков. Создание информационной базы в данном случае — лишь малая часть тех процессов, которыми следовало бы интересоваться руководителям. Если высшее руководство не проявляет интереса ни к чему, кроме продаж, то не стоит ожидать этого от рядовых сотрудников.
В итоге если в компании хорошо организованы процессы отчуждения интеллектуальной собственности и разделения знаний, то все участники проекта автоматически делаются «условно заменимыми».
Почему это хорошо и почему к этому стоит стремиться:
— Это неплохо компенсирует риски компании при выходе участников из проекта.
— Это полезно для команды, т.к. в случае отсутствия коллегу можно подменить без ущерба для проекта.
— Это хорошо для сотрудника, т.к. значительно облегчает передачу дел последователям.
— Это плохо для «незаменимого» сотрудника, который боится потерять своё место.
На самом деле мы все в той или иной мере боимся потерять работу. Но больше всего этого боятся низкоквалифицированные «специалисты», для которых поиски нового места могут быть весьма проблематичны. Если достаточно расслабиться и позволить себе быть «незаменимым», то это качество непременно в будущем станет тем якорем, который будет мешать в достижении новых карьерных высот и может серьёзно повредить профессиональной репутации. Настоящие специалисты не боятся документирования, но нужно признать, что и не особо любят заниматься этой скучной, хотя и полезной работой.
Очень хочу сделать акцент на «условности» заменимости. Потому что нет никакой гарантии того, что человек, который будет взят на замену, будет настолько же ответственным и квалифицированным — хороший руководитель всегда понимает это. Если повезёт. По крайней мере, я всегда искренне на это надеюсь.
Кто и когда этим занимается
Документированием технической части — вполне очевидно — занимается тот, кто эти технические решения создаёт. Если техническое решение кажется элементарно простым, понятным и прозрачным — разумеется, нет смысла снабжать его лишними описаниями. Если же не все так тривиально, а вы все равно полагаетесь на свою супер-память, а ваши последователи «и так разберутся, если не дураки», — это целиком лежит на вашей совести.
Однако если системный архитекторили техлиднастоятельно просит сделать «пару строк» в вики по технической реализации — стоит его послушать, если не из чувства глубокого уважения, то хотя бы из жалости. В силу своей патологической занятости вряд ли этот человек будет просить дважды, а в случае чего — голову будут снимать именно ему.
Описания бизнес-процессов очень важны сточки зрения развития продукта, и ими обычно занимаются аналитик (BA | SA) или проджект-менеджер (PM). Всё очень просто — в норме они больше всех знают о процессах внутри проекта, поэтому никто лучше них с этой работой не справится.
Итак, вы решили сменить проект. Если он уже запущен, то стоит поинтересоваться:
1. Наличием документации и её спецификой (о чём она — техническая, пользовательский help, бизнес-процессы & so on);
2. Кто занят в процессе поддержки? Если это сами программисты — будете иметь дело с технической документацией. Если это аналитик или проджект-менеджер — может быт, вам повезет с описанием бизнес-логики. Специальный технический писатель и пользовательская документация — тоже неплохо: оттуда, как правило, можно выудить знания о логике функционирования приложения. Как бы то ни было, документацию пишут люди, и она во многом зависит от их специальности.
Если записей по бизнес-процессам нет, спросите о возможности их появления: вас должны интересовать перспективы развития проекта. Вы должны понимать, что чем проект крупнее и древнее, тем сложнее в нём процессы, и без вменяемой документации (желательно слоистой или модульной) очень легко утратить контроль. А это всегда приводит к одному и тому же плачевному результату. О масштабах и симптомах этой катастрофы можно почитать всё в той же книге Роберта Мартина «Чистый код».
В новом проектестоит узнать, планируется ли ведение документации, в каком виде, кто этим будет заниматься. И вообще, побольше разузнать о том, как ваша потенциальная команда видит себе будущий процесс разработки.
Если документации бизнес-процессов нет, а вы работаете в старом проекте и не собираетесь оттуда уходить, но есть желание исправить положение: как быть и что делать — об этом я напишу в одной из своих следующих заметок.