Вступление

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

В заметке так же рассматривается больной вопрос трудностей с выплатой зарплаты и как их можно эффективно решать.

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

Многие высказанные в заметке мысли применимы и к другим типам ИТ-проектов. Будьте с этим осторожны, так как автор писал лишь о том, с чем имел непосредственный опыт. Действительность же иных ИТ-проектов может выглядеть схоже, но их реальность требовать для достижения успеха полностью противоположных шагов. Лишь глубокое понимание своего проекта позволяет переносить приёмы между соседними типами проектов и получать от этого значительную пользу.

В заметке роль руководителя проекта разделена на роли технического руководителя и бизнес-руководителя. Для ИТ-проектов это традиционное деление. Бизнес-руководителя в зависимости от типа организации обычно именуют просто руководителем проекта, менеджером проекта или CEO. Технического руководителя обычно именуют CTO, руководителем отдела, архитектором, тимлидом, главным программистом или ведущим программистом — опять в зависимости от типа организации и приоритетом в пользу организаторских, программистских или архитектурных способностей руководителя.

Бизнес-руководителя на протяжении всего текста можно было бы называть просто руководителем проекта и это было бы всем понятно, но он всегда будет называться именно бизнес-руководителем. Это сделано для того, чтобы вы понимали простую истину: у технологически сложного ИТ-проекта всегда два руководителя, из них один ведущий (бизнес), другой ведомый (технический), но их два. Если технический руководитель забудет, что он тоже руководитель и тоже несёт определённую ответственность за успех проекта, то в условиях острого ограничения по времени это с большой долей вероятности приведёт к краху проекта.

Заметка получилась размером около 80 тыс. символов и потребует при быстром чтении около двух с половиной часов. Она будет интересна руководителям проектов, инвесторам и тем из разработчиков, кто интересуется стартапами и проектным подходом к разработке.

Об авторе

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

Типичной схемой работы является «найм с рынка, разработка архитектуры, найм с рынка команды разработчиков, разработка руками разработчиков, самостоятельная реализация наиболее сложного функционала, запуск приложения и через некоторое время выход из проекта» — настоящий хардкор.

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

К чему приводит нехватка времени

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

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

Рост трудности найма с развитием проекта. Чем дольше разрабатывается проект, тем больше написано кода, тем более сложная логика реализована, тем новичку больше приходится разбираться в имеющемся коде. Кроме того, постоянное откладывание рефакторинга даже в условиях качественного CodeReview приводит к тому, что код местами становится трудно понятен. Это может приводить к тому, что уже через три месяца после начала написания кода новые нанимаемые программисты будут быстро уходить и текучка по новым разработчикам достигнет 100%. Опытный технический руководитель может справиться с этой трудностью заблаговременно, начинающий — нет.

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

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

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

Все всё понимали. Проект был запущен в срок с качеством кода сильно превышающим среднерыночный для крупных компаний.

Накопление плохого кода из-за откладывания рефакторинга. Острая нехватка времени приводит к тому, что на рефакторинг выделяется время лишь в ситуации, когда код явно труден для доработки. Более того, когда добавление функционала в данный участок кода приводит к выполнению большого объёма работы по отладке ошибок. Если руководству проекта повезло и тимлид хорош, то он сможет отслеживать наиболее проблемные участки кода и информировать о том, когда они потребуют рефакторинга и в каком объёме. Обычно такими участками является часто обновляемый код: пару строк добавили в рамках одной задачи, ещё тройку в рамках другой, строчку в рамках третьей и к десятой правке в коде вермишель. Виновного среди программистов нет. При этом защититься от образования такой вермишели даже с помощью CodeReview и продвинутого тимлида весьма проблемно. Такой код нужно время от времени рефакторить, а у проекта острая нехватка времени.

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

Решению конфликтов сильно поможет понимание того, что конфликт в группе разработки обычно возникает из желания участников сделать работу лучше и быстрее. При этом решения для этого используются разные. Иногда с разными приоритетами на скорость или качество. Это производственные конфликты, не личностные. Такие конфликты лучше всего решать обучением сторон и совместным принятием решения, а не поиском правого или виноватого.

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

Бизнес-руководитель проекта

Бизнес-руководитель проекта является самым важным человеком на проекте. Именно он является источником идей, точкой связи с конечной аудиторией и представителем пользователей в проекте. В случае наличия заказчика он же является и представителем интересов заказчика. При этом следует помнить, что проект работает на конечного пользователя — только конечный пользователь примет решение был ли проект успешен и можно ли пользоваться созданным продуктом. В стартапе роль бизнес-руководителя исполняет предприниматель, один из основателей стартапа.

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

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

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

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

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

С кем не стоит связываться

Не следует входить в проект, возглавляемый людьми, не понимающими ИТ и не имеющими опыт работы в ИТ. Владелец ларьков будет относится к команде разработке как к персоналу ларька. Владелец строительной компании как к таджикам. Бывший руководитель службы безопасности как постоянным нарушителям режима безопасности. Человеку трудно сменить стиль руководства.

Следует избегать входить в проект, который возглавляют люди не занимавшиеся основным видом деятельности, характерным для проекта. Бывший высококлассный системный администратор не лучший бизнес-руководитель проекта по разработке мобильных приложений. С другой стороны, если такой человек руководит ИТ-проектами более 5 лет, то, наоборот, он может внести в проект много полезного.

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

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

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

Технический руководитель проекта

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

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

Возьмём, например, основные стеки технологий автора:

• Lotus Notes — Lotus Domino — Lotus Workflow — Lotus Domino.Doc ;
• Linux — Nginx — Apache / PHP_FPM — MySQL / PostgreSQL — PHP / Perl / C ;
• Linux — Node.JS — Tarantool / Redis — LuaJIT ;

Языки вне стеков: C++, Assembler, разнообразные диалекты Visual Basic, JavaScript, TypeScript, Go, Java, Formula и всякие Fortran и Pascal в юности.

Из операционных систем удалось разрабатывать во всех MS DOS начиная с 3.0, всех Windows начиная с 3.1, OS/2, CentOS, Ubuntu, Debian, openSUSE, AstraLinux и давно уже на FreeBSD.

Администрировать довелось в основном CentOS, Ubuntu, Debian, openSUSE и AstraLinux.

Из фреймворков: Symfony2, Symfony3, Kohana 3, Yii 2, React Native, SailsJS, ExpressJS, MFC, Bootstrap 3, OWL for C++ и др.

Из прочего инструментария пришлось разбираться и промышленно использовать ElasticSearch, MongoDB, Beanstalk, BerkeleyDB, инфраструктуру Docker, Composer, Capyfony, RabbitMQ, Memcached, Git, Jira, RedMine, PHPUnit, SphinxSearch, Axshare, WinAPI и разнообразные API для С типа Rational Rose, MySQL, Domino.Doc и другие.

Из IDE: NetBeans, PhpStorm, Visual Studio, блокнотик, редактор mc и vi.

Венчает всё это навык верстать страницы точка-в-точку в ситуациях, когда верстальщики среднего уровня мастерства уже не справляются и говорят, что это сверстать невозможно.

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

Архитектурным навыкам в самых разнообразных видах, ракурсах и разрезах посвящена вторая половина этой заметки. Они для технического руководителя проекта являются ключевыми. Поэтому мы будем их рассматривать далее отдельно и предельно подробно.

Остаются руководительские, управленческие и организаторские. Так называемые софт-скилы. Софт-скилы желательно наращивать именно в указанном выше порядке. То есть сначала руководительские, затем управленческие, затем организаторские.

Навыки руководства позволяют распределить сферы деятельности между разработчиками, объяснить им что именно нужно делать и почему, а кроме того помогать им решать текущие вопросы, разруливать конфликты интересов и учить вместо того, чтобы критиковать. Так же они являются критичными при найме разработчиков — именно они позволяют понять кто пришёл на собеседование, что он на самом деле может и как он впишется в разработку сейчас и со временем.

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

Организационные навыки позволяют структурировать в команде роли, подобрать под роли максимально подходящих людей и запустить механизмы самоорганизации в рамках получившейся организации так, чтобы участники команды разработки выстроили процесс разработки необходимым образом.

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

Можно ли в небольшой группе разработки обойтись слабо развитыми навыками руководства и управления? Можно. Для этого достаточно организовать Scrum по Scrum Guide. Это в чистом виде фреймворк для руководства без руководства и управления без управления. В условиях острой нехватки времени обычно неприменим из-за психологических особенностей бизнес-руководителя проекта и спонсора.

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

Разработчики

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

Посему если не проходит по навыкам — не нанимайте. Он не успеет прокачать необходимые навыки. Если туповатый, вялый или мямля — не нанимайте. Он не сможет работать быстро. Если не готов принимать ответственность за свои решения — не нанимайте. В первые месяцы у технического руководителя проекта не будет времени чётко ставить все задачи, поэтому каждому разработчику придётся принимать решения близкие к ключевым в рамках их участка разработки и нести за них ответственность. Если не нравится человек — не нанимайте. Работа с людьми, которых приходится терпеть, постепенно подтачивает дух и со временем делает работу тягостной и печальной. Если считает, что знает истину — не нанимайте. Быстрая разработка это про умение выбрать между двумя достаточно хорошими вариантами зная при этом, как сделать наилучшим образом, почему на это нет времени и почему проект выживет после принятия таких решений и не выживет с реализацией согласно наилучшей практике.

Много ограничений? Много. И они серьёзнее, чем может подумать неискушённый человек.

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

В зависимости от своей внутренней структуры проекты будут накладываться и иные требования. Именно проекты, не вы. Понимая проект, вы видите его потребности и в этом плане проект как бы сам решает, кто будет идеальным разработчиком, и роль руководства проекта лишь понять это. Хотя, конечно же, все решения принимают люди и «проект сам решает» лишь означает, что бизнес-руководителю когда-то пришлось наложить такие ограничения на проект, которые приводят к этим «требованиям проекта».

Для каких-то проектов ради достижения высокого качества продукта требуются перфекционисты. Для других критично важны люди, умеющие пересилить в себе желание сделать идеально ради того, чтобы быстро сделать работающую первую версию. Для третьих требуются узкие специалисты и технический руководитель проекта выступает как интегратор их труда в единый продукт. Для четвёртых — разработчики с широким кругозором и кто-то из разработчиков, а может и технический руководитель, довёрстывает то, что не может сверстать верстальщик; исправляет в JavaScript-е то, что не может исправить frontend-разработчик; реализует в серверной части то, с чём не справляется backend-программист. Для пятых невозможно обойтись без активной коммуникации внутри группы разработки и это требование к умению общаться по делу и помогать друг другу будет перевешивать даже профессиональные навыки.

И это ещё не всё. В условиях острой нехватки времени руководство проекта не может ждать две недели, пока разработчик уволится с текущего места работы. Так же оно не может принять риск того, что за эти две недели разработчик успеет передумать или пройдёт собеседование и устроится в другую компанию «забыв» вам про это написать. Руководству проекта нужен человек, готовый выйти в течение нескольких дней и, если ему что-то не понравится, то заменить его в течение следующей пары дней.

Вот такие ограничения на кандидатов.

Планирование

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

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

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

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

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

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

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

План работ в системе отслеживания задач типа Jira описываться не будет из-за обилия хороших статей на это тему. Автор заметки хочет отметить лишь важные моменты. У задач должна быть достаточно разветвлённая система статусов. Они могут быть не объединены в настроенный документооборот, но они должны быть описаны и утверждены. Только они помогут разбираться с текущими статусами задач не отвлекая разработчиков от работы. Вторым важным моментом является фиксация всех принятых решений в рамках задач в комментариях к ним. Все устные договорённости тоже должны быть зафиксированы. Это избавит от конфликтов что должно быть сделано, а о чём договорились не делать.

План работ со списком функционала в рамках каждого этапа достаточно прост: дата начала этапа, дата окончания этапа и крупномасштабный список функционала. Нужен для быстрого понимания когда и что делается.

План работ в виде списка всех задач в таблице Excel описывает как список задач, так и кто делает каждую из них. Это примерно 300-500 задач, которые объединяются в блоки. Каждый блок обычно соответствует отдельной функции. Например, «реализация уведомления о событии» является блоком, а «создание дизайна писем-уведомлений», «вёрстка писем-уведомлений по дизайну», «встраивание вёрстки в код» и «реализация логики отправки уведомлений при возникновении события» — это отдельные задачи, которые выполняют разные люди. Эти люди указываются в виде исполнителей по каждой из задач. Для каждой задачи плана работ прописывается задача в Jira и номер её попадает в таблицу плана работ. Задачи в Jira объединены в рамках истории, соответствующей блоку. Кроме того, у каждой задачи есть плановый объём работ в часах, фактический объём работ, плановая дата завершения и фактическая дата завершения. У каждого функционального блока есть плановая дата завершения всего блока и фактическая дата завершения. В довершение у каждой задачи и у каждого блока есть свой статус. У задачи те же статусы, что и в Jira, а у блока лишь два статуса «пустое поле» и «Готово» — такой вариант статусов вполне позволяет отслеживать текущее состояние дел всем заинтересованным лицам.

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

Если разработчиков немного и выставлением задач-тестированием занимается технический руководитель проекта, то в список задач можно отдельными строками помещать лишь исполнение задач, а всё остальное относить на время технического руководителя проекта. В такой ситуации 60% времени будет учтено в строке по самой задаче, 5% времени по задаче «Тестирование» в конце списка всех задач данного этапа, 20% времени по задаче «Исправление ошибок» и 15% времени занимаемые постановкой задачи, интеграцией её в приложение и контролем исполнения задачи будут учитываться как постоянная управленческая работа технического руководителя проекта.

Если разработчиков более пяти, то для улучшения управляемости проектом следует все эти подзадачи учесть как отдельные задачи и тогда у каждой задачи плана разработки появляются дополнительные параметры по каждой подзадаче: исполнитель, объём работ и срок.

Объём работ измеряется в часах. Минимальная единица исполнения задачи — час. Если задача мелкая и вынесена в отдельный пункт лишь с целью контроля, то может быть полчаса. Мельче имеет смысл планировать только объём работ по простым ошибкам, но они в план работ не попадают. Минимальная единица объёма работ для прописывания задачи, тестирования и исправления по задаче — 1/4 часа. Данная деятельность выполняется в пакетном режиме (например, прописываются сразу 5 задач или тестируются сразу все задачи, выполненные за день, или правятся ошибки по всем задачам, протестированным до этого пачкой), поэтому сам пакет подзадач занимает час-полтора, а каждая отдельная подзадача выполняется относительно быстро. Следует лишь учесть, что на первые 10 задач каждого нового разработчика будет тратится непропорционально большое время на составление длинного списка огрехов, обнаруженных во время Code Review. Спустя какое-то время разработчики привыкают писать правильно и Code Review умещается в 10-15% времени отводимого на тестирование.

У планирования есть целый ряд отрицательных эффектов. Самым важным из них с точки зрения темы данной заметки является то, что если время по задаче выставлено не разработчиком, а его начальником, то разработчик работает вдвое менее производительно, чем если бы оценка времени не выполнялась вообще. Если время по задаче оценивалось самим разработчиком, то разработчик работает всего лишь на четверть менее эффективно, если бы он делал эту оценку. Это доказано 30 лет назад и стало широко известно тогда же, что не мешает руководителям требовать от разработчика укладываться в навязанные ему сроки. Готовы заплатить двукратным проигрышем по скорости в условиях острой нехватки времени?

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

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

Учёт рабочего времени

Объём работ имеет подвох, который трудно объяснить неискушённому бизнес-руководителю проекта. Лучше всего механизм этого подвоха показать на простом примере. Технический руководитель посчитал, что 10 задач для разработчика серверной части потребуют 24 часа работы. Задачи были созданы в системе отслеживания задач, разработчик выполнил задачи и в ходе выполнения каждой задачи честно отмечал затраченное на каждую из них время. Суммарное время получилось 24 часа и совпало с проектным. Зарплату он получил за 30 часов. Последнюю задачу перевёл в статус «Выполнено» через четыре дня после начала работы над первой вместо трёх. Занимался он только этими задачами. Куда делись эти 30 — 24 = 6 часов?

Фишка в том, что разработчик не может работать 8 часов в день. Он ходит в туалет раза три-четыре за 8 часов. Отдыхает каждый час минут по пять и этот отдых — часть техники безопасности, без него работать невозможно. Чай себе делает раза четыре в день. В общем, программист на задачи тратит лишь 6-6.5 часов рабочего времени. В ситуации аврала доходит до 7 часов, но долго так продолжаться не может — организм не выдерживает постоянного сидения за компьютером и программирования. И вот эту разницу в полтора-два часа между оплачиваемым временем и временем фактической работы над задачами необходимо как-то учитывать.

Наиболее корректным вариантом учёта этого расхождения является расчёт плана работ с учётом фактической ежедневной 6-часовой работы над задачами. То есть объём выполнения задач измеряется в фактических часах без учёта туалетов, отдыха и чаепития, а день считается равным 6 часам. При этом время фактического исполнения задач меряется тоже без учёта перерывов. То есть, например, в Jira перед уходом в туалет разработчик останавливает таймер отсчёта времени фактического исполнения задачи, после возвращения из туалета — включает его вновь и продолжает работать по задаче.

Трудностью такого подхода является разъяснение бизнес-руководителю и заинтересованным лицам вот этой разницы. То есть почему они платят за 8 часов, а работа осуществляется 6 часов, почему 8-часовой рабочий день планируется как 6-ти часовой. Ещё хуже становится, когда в рамках корпоративной системы учёта рабочего времени требуется заполнять листы отработанного времени с расписыванием их по каждой задаче. Хуже может быть только обязательная интеграция системы отслеживания задач с выгрузкой сырых данных в корпоративную систему.

Ради избежания этого объяснения многие технические руководители проектов просто увеличивают плановое время по задачам на треть, а время фактического исполнения задачи меряется с учётом всех туалетов и передыхов, то есть в размере 8 часов за день. Данный подход приводит к серьёзному искажению отчётности и неадекватности при пересчёте плана на базе данных по времени выполнения типичных задач каждым из разработчиков.

Вход в проект

Следует избегать входить в проект разработки любого программного обеспечения в условиях острой нехватки времени. Данное утверждение вдвойне верно для технологически сложных проектов. Это знают все работающие в ИТ. Но некоторые всё равно идут на данный шаг. Кто-то потому что такие проекты хорошо оплачиваются. Кто-то потому что они бросают вызов разуму. Кто-то потому что других предложений о работе нет. А кто-то просто работает в ИТ и привык, что проекты с разумными сроками здесь так же редки, как тёплые июньские дни этим летом в Москве.

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

То есть все три важных вопроса — это про людей. Не про технологии. Не про методологии. Не про бюджет. Про людей. Программные продукты делают люди руками других людей и поэтому именно они являются следующим по важности риском после сжатых сроков.

Начало разработки

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

Из личной практики. В одном из проектов автор данной заметки за три с половиной дня нанял Android-разработчика, iOS-разработчика и двух NodeJS-разработчиков, которые вышли работать со вторника (бизнес планирует календарно, а целевая дата начала непосредственной разработки — первое число месяца — приходилась на вторник), на следующий день после найма последнего участника команды. Такие гибридные случаи бывают, но они редкость и всё равно подпадают под второй вариант: мы сначала планируем и только потом нанимаем, а планирование происходит по фактической ситуации в которой неизвестно про будущие успехи найма.

И так, у нас есть техническое задание в виде какого-то макета интерфейсов приложения в каком-нибудь Axure/Axshare или готовые дизайн-макеты в Photoshop, есть желающие побыстрее начать разработку бизнес-руководитель и спонсоры проекта и есть технический руководитель проекта, который должен организовать разработку максимально быстро. Что делать техническому руководителю?

Для начала следует прописать общую схему работы приложения. Нарисовать то, как данные текут от пользователя в базу и от базы к пользователю. Какие данные текут: чтения из базы, записи в базу, чтения с диска, записи на диск, преобразования изображений и т.д. В каком объёме эти данные текут.

Следует помнить, что для каких-то данных критическим параметром будут гигабайты трафика, для каких-то — количество чтений/записей в базу, для каких-то — чтения с диска, для каких-то необходимо считать в процессах обработки (например, поисковых запросов на полнотекстовый поиск в секунду или сохранений изображений с переконвертированием в разные размеры на процессор). Куда придётся основная нагрузка. Когда смотрите на нагрузку обращайте внимание на диски. Часто начинающие упускают, что основным ограничивающим фактором являются IOPSы — количество случайных чтений в секунду — и простои приложения из-за ожидания ответа от базы или дисков.

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

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

Из личной практики. Использования незнакомых инструментов стоит остерегаться, но не стоит бояться. Автор заметки однажды столкнулся с необходимостью разрабатывать интернет-приложение на полностью незнакомых инструментах. В ходе прописывания архитектуры и прояснения особенности возникающих нагрузок стало ясно, что из знакомого при разработке можно было использовать лишь Sphinx и Docker. Итогом было успешно построенное приложение и целая пачка новых изученных инструментов в виде Lua, NodeJS, Tarantool, React Native и др.

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

Нижним уровнем интерфейсов выступают репозитории. Репозитории отвечают только за отдачу запрашиваемых из внешних источников данных (база данных, поисковый движок, кеш) и передачу данных во внешние системы (базу данных, поисковый движок, приложения отправки почты и т.д.). Большим плюсом репозиториев является радикальное ослабление связи кода приложения и внешних систем. Решение о выборе поставщика услуг доставки SMS или итоговой базе данных может быть принято в последний момент.

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

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

Итогом было успешное встраивание в приложение Tarantool, он полностью оправдал ожидания.

Верхним уровнем выступает API. В случае с приложением типа клиент-сервер это традиционное REST API или Websocket API. В случае более традиционного сайта с MVC-архитектурой это промежуточный слой из одного класса между моделью предметной области и контроллером. Так же в случае традиционного сайта важно прописать правила именования ссылок, перечень самих ссылок и сопоставление им контроллеров.

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

Если техническому руководителю проекта повезло и удалось обосновать найм тестировщика, то он может оказать всем большую услугу. А именно, написать функциональные и интеграционные тесты на API. Так как API полностью покрывает бекендную часть функционала, то по этим тестам можно отслеживать фактический прогресс разработки бекенда интернет-приложения — это просто доля успешно отработанных тестов API. Так же данные тесты позволят узнать, какой из методов API и с какими параметрами перестал работать. Это становится критично важно через 5-6 месяцев быстрой разработки.

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

Автор заметки не стал писать про важность организации среды разработки, стандартов форматирования кода, правил именования веток Git-репозитория, CI, CD и т.д. Все это знают. И это, действительно, важно. Но гораздо важнее следовать этим важным практикам, чем просто знать об их важности.

Тестирование

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

Тестирование можно разделить на:

• простое ручное тестирование, при котором тестирующий приложение знает, что разрабатывалось и исправлялось и вручную тестирует изменения руководствуясь лишь своей логикой;
• ручное тестирование по списку кейсов или плану тестирования, а в пределе — по методике приёмо-сдаточных испытаний в рамках ГОСТ 34.603-92;
• автоматизированное модульное тестирование;
• автоматизированное функциональное тестирование;
• автоматизированное интеграционное тестирование;
• автоматизированное тестирование на базе спецификаций;
• и т. д. (в условиях острой нехватки времени до этого пункта проект не дойдёт никогда в силу особенностей бизнес-руководства).

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

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

И так, при определённой сноровке первые полгода можно обойтись без автоматических тестов без особых последствий. Ключом к этому являются хорошо продуманная архитектура с минимальной связностью различных частей приложения и постоянный Code Review: отслеживание нарушений в архитектуре, изживание неявных зависимостей и обучение программистов на примере их собственного кода как писать яснее, понятнее и правильнее.

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

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

Тестами на данном этапе, этапе неустойчивого кода, следует покрывать API: времени для написания этих тестов тратится немного и при этом быстро становится ясно, где упало. Эти же тесты проще всего «продать» бизнес-руководителю проекта, так как он понимает, что именно оптимизируется и что эти тесты непосредственно решают уже осознанную им проблему: программисты правят в одном месте, а падает в другом.

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

В условиях острой нехватки времени никто и никогда не даст времени на написание модульных тестов даже понимая необходимость данных тестов. Бизнес-требования так устроены, что бизнес-руководитель проекта вынужден регулярно выдавать новый результат. Вариант «мы остановим разработку, потратим треть уже затраченного времени — месяца три — на написание модульных тестов и приложение опять станет устойчивым» не пройдёт. Автор заметки не сталкивался, чтобы такой вариант кто-то согласился реализовать. Автор заметки не слышал, чтобы кто-то смог его пробить. Автор заметки даже не читал о подобных чудесах в литературе.

Обычно используется подход с плавным покрытием кода тестами. Либо покрывается лишь новый функционал, а старый постепенно становится легаси; либо покрывается тот функционал, который затрагивается изменениями и правками ошибок; либо используется схема «тронул класс — покрой его тестами».

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

Что делать, если проблема назрела, а денег нет, то есть проект развивается по первому варианту? В такой ситуации следует покрывать тестами лишь наиболее проблемный код. Его можно выделить либо по местам локализации ранее найденных ошибок, либо по местам наиболее долгого исправления ошибок, либо изучая код на наличие в участках кода большого количества связей, зависимостей и сложной логики. Для этого необходимо с начала проекта вести лог ошибок (например, в виде билетов на исправление ошибок в Jira), замерять время исправления ошибок, опрашивать разработчиков на предмет того, какие участки кода им кажутся сложным и самому понимать код. Последнее требуется скорее для того, чтобы отбросить те предложения программистов, которые затрагивают улучшение и без того вполне годного кода (то есть не такого ужасного, как остальной).

И последнее. Замечено, что если все тесты выполняются менее 3-х секунд, то программистам не составляет труда их запускать. Особенно если их запуск выведен в браузер и делается простым обновлением страницы. Если тесты выполняются более 10 секунд, то программисты начинают лениться и отправлять на сервер код, в который в последний момент была внесена правка, а ждать прогона тестов не хотелось. Так же замечено, что регулярное наличие в основной ветке непройденных тестов сильно демотивирует разработчиков на запуск тестов.

Написание полного набора тестов занимает 30% всего времени разработки. Ручное тестирование, исправление, перетестирование и так пока не заработает занимают 40% всего времени. При этом автоматические тесты гарантируют некоторый заранее определимый уровень качества кода. Выбор за вами.

Инфраструктура

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

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

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

Признаком необходимости такого деления является желание бизнес-руководителя сохранить данные на тестовом сервере. Если технический руководитель проекта видит, что какие-то данные стали ценными, то ему следует предложить разделить окружение на два: со стабильными данными и с тестовыми.

После появления демонстрационного окружения обычно достаточно часто появляется осознаваемая потребность в тестовом окружении. Его назначение состоит в том, чтобы бизнес-руководитель мог убедиться в работоспособности приложения до размещения версии на демонстрационном окружении.

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

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

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

Документирование

Целью документирования является понимание участниками разработки того, что же было когда-то сделано. На документировании в условиях острой нехватки времени экономят практически всегда. И правильно делают. На самом деле, важно следующее:

• код должен быть максимально понятен любому разработчику без комментариев;
• внутренние зависимости кода должны быть очевидны и наглядны;
• логика исполнения кода должна быть обозрима и использовать только явные зависимости;
• для каждого сложного процесса должна существовать диаграмма логики процесса, ссылка на диаграмму должна находиться в коде во всех методах, которые затронуты процессом;

Для этого достаточно выполнить следующее:

• код должен иметь стандарты кодирования для всех используемых языков;
• код должен прогоняться через инструмент проверки соблюдения стандартов кодирования;
• наименования схожих по функционалу объектов должны быть стандартизированы;
• разработчиков необходимо стимулировать писать длинные имена классов, длинные имена функций и длинные наименования переменных — современные IDE с их подсказками позволяют использовать такие имена без затраты дополнительного времени на набор букв, при этом говорящие за себя названия значительно ускоряют понимание кода и его написание;
• код должен проходить процедуру CodeReview и отправляться на доработку при малейшей неясности с разъяснением разработчику, к чему данная неясность может привести.

Так же желательно полностью задокументировать инфраструктуру.

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

Начало эксплуатации

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

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

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

Начало эксплуатации заканчивается после того, как продукт может существовать без разработчиков. То есть первым стабильным релизом, запуском MVP. С этого момента продукт переходит в стадию собственно эксплуатации.

Подготовка к началу эксплуатации

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

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

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

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

Все должны понимать, что перед релизом необходимо внимательное тестирование. И только после того, как технический руководитель уверен, что релизы проходят серьёзное тестирование, вот только тогда он может договариваться о регламенте исправления ошибок во внерабочее время. Регламент следует прописать так, чтобы участие технического руководителя по возможности ограничивалось SMS-ками о проблеме и её решении.

Описанный сложный социальный процесс тоже часть подготовки к началу эксплуатации.

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

Технический руководитель проекта может использовать:

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

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

Развитие продукта после начала эксплуатации

Положа руку на сердце, после запуска MVP желательно переписать созданный продукт с нуля. Собственно в этом и состоит назначение MVP: участники проекта быстро создают минимально годный продукт, смотрят как на него реагирует целевая аудитория, изучают архитектурные особенности системы, а затем на основе накопленного опыта создают с чистого листа Действительно Стоящую Вещь.

Все это знают. Никто так не делает. Чуть реже чем всегда на базе будки пытаются построить небоскрёб. Результат как бы заранее предсказуем, все это изначально понимали, но после возведения небоскрёба удивляются, почему опять вышло вкривь и вкось.

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

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

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

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

Ещё раз отмечу, что практика однозначно показывает, что современные фреймворки разработки и шаблоны проектирования в умелых руках позволяют радикально снизить остроту данной проблемы.

Выход из проекта

Выходы из проекта можно поделить на хорошие и плохие. Хороший выход сохраняет проект, плохой его убивает. Лучшим выходом является продажа своей доли проекта вместе с основателями с согласия инвесторов. Худшим — выход посреди проекта с уводом части команды разработки в конкурирующий проект. Бывают нюансы, но в целом как-то так.

У продуманного технического руководителя проекта первой точкой принятия решения является момент входа в проект, второй — запуск MVP, а третьей — частичный выход из проекта основателей.

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

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

Если у проекта кончились деньги

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

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

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

Практика показала, что даже если есть возможность заплатить работникам сразу, а такое бывает, то технический руководитель проекта получит свои деньги спустя некоторое время. Часто в несколько этапов. Основной причиной этого являются размеры выплат. Зарплата технического руководителя проекта составляет от 25 до 40% фонда оплаты труда группы разработки и это весомая часть общей суммы долга.

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

Как часто люди не получают своих денег? Отпускные, оценочно, в трети случаев. Зарплату-полторы плюс отпускные — в одном из десяти. Автору заметки удавалось полюбовно договариваться всегда и получить все свои деньги в пяти из пяти стартапов, в одном из них с серьёзной задержкой. В свою очередь, в нескольких своих стартапах атору удалось расплатиться со всеми работниками на момент их увольнения, а инвесторам выплатить все занятые деньги спустя некоторое время.

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

И так, допустим, что техническому руководителю надоело ждать свои деньги и жить «завтраками» от спонсора. Что ему стоит предпринять?

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

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

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

Далее следует дождаться начала переговоров (инициатор — спонсор) и договориться о графике выплаты честно заработанных денег.

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

Вход в новый проект

35 тысяч символов тому назад был схожий по названию раздел, но его внутреннее содержание было совершенно иное. В нём обсуждалось что техническому руководителю делать при входе в имеющийся проект. Данный же раздел посвящён тому входу в проект, который технический руководитель проекта держит в голове во время проекта текущего.

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

Практика показывает, что в России рынок рекомендаций практически не развит. В этом плане репутация как бы бесполезна. Сертификаты не работают. На них работать бессмысленно.

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

Хорошо работает место получения образования. Очень хорошо работает фактический опыт, который помогает на собеседованиях показывать свои компетенции в интересующих бизнес-руководителя областях, а в реальной работе быстро решать возникающие трудности. Так же прекрасно помогают найти общий язык человеческие качества и способность понимать других. Вообще, умение излагать сложные технические темы простым языком собеседника весьма редкое качество российских технических руководителей проектов. Оно даёт значительное преимущество перед другими кандидатами. Для технарей это трудно дающийся навык, но его стоит постоянно развивать. Софт-скилам была посвящёна половина раздела «Что необходимо уметь».

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

Заключение

Есть ли смысл входить в подобные проекты? Это сильно зависит от ваших личных приоритетов, умений и жизненной стратегии. Надеюсь, что данная заметка помогла вам сделать осознанный выбор или поможет это сделать в будущем, когда вы будете принимать решение входить в подобный проект или отказаться в пользу более спокойной работы.

Автор: GreyStrannik

Источник