Владимир Бычко об управлении проектами

пиэм разъясняет, предостерегает, рекомендует

Категория: Разработка

Написание требований методом набегающей волны

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

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

  1. Хливкие шорьки
  2. Хрюкотающие зелюки
  3. Мюмзики в мове
  4. Бармаглота сын
  5. Злопастный Брандашмыг

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

У вас должно быть общее понимание, что нужно делать в рамках каждого пункта, но без деталей.

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

После того, как первый пункт будет реализован, презентуете его заказчику.

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

И только после этого вы садитесь расписывать требования ко второму пункту или пункту, ставшему вторым. Этот подход здорово экономит время на анализ и проектирование, минимизируя объём требований, выкинутых в мусорку.

Изображение с videoinfographica.com

Пирамида принятия решений, уровни менеджмента

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

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

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

Микрокоманды в разработке

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

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

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

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

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

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

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


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

Созвоны с коллегами в Scrum

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

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

Оценка задач

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

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

Статус

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

Планирование спринта

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

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

Ретроспектива

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

Демо

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

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

Дейлики

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

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

Неприкосновенность оценки

Принцип неприкосновенности оценки

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

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

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

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

Типовые вопросы для собеседования на технического менеджера проектов

 

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

Что такое DNS?

Domain Name System — это технология, которая позволяет браузеру вроде Firefox, Chrome или Edge найти запрошенный пользователем сайт по его имени. Если быть точным клинически, эта служба позволяет сопоставлять IP-адрес сервера с доменным именем. 

Каждому имени сайта соответствует набор цифр формата 000.000.000.000. Этот набор называется IP-адресом, примером реального IP-адреса является 192.168.0.154 или 203.113.89.134. Когда пользователь вводит в адресной строке браузера имя сайта, например google.com, компьютер запрашивает IP-адрес этого сайта на специальном DNS-сервере и после получения корректного ответа открывает сам сайт.

Вопрос со звёздочкой. Как происходит сопоставление IP-адреса и сайта, если на одном сервере несколько сайтов?

DNS-серверы отвечают за то, чтобы несколько доменов вели на IP-адрес, а веб-сервер с помощью механизма виртуальных хостов распределяет к какому из сайтов.

Теперь детали, как это работает. В частности, протокол HTTP 1.1 включает в себя заголовок, называемый «host:», который указывает, к какому веб-сайту на конкретном сервере клиент пытается получить доступ.

Таким образом, если snoopy.net и woodstock.org совместно используют 192.0.32.10 и ваш браузер пытается получить контент из http://snoopy.net/doghouse конкретного http-запроса, он будет выглядеть так:

GET /doghouse HTTP/1.1
Host: snoopy.net

Если желаемым URL является http://woodstock.org/seeds запрос будет выглядеть

GET /seeds HTTP/1.1
Host: woodstock.org

В обоих случаях между вашим компьютером и портом 80 сервера будет TCP-сокет. Сервер будет знать, как получить содержимое из /var/www/snoopy.net или /var/www/woodstock.org/ на основе заголовка Host.

Были бы другие заголовки для файлов cookie и другие вещи, такие как тип браузера и разрешенный контент, но именно заголовок «Host» — это то, что позволяет веб-серверу знать, какой виртуальный веб-сайт желателен.

Что такое кэш?

Кэш — это память с большей скоростью доступа, предназначенная для ускорения обращения к данным, содержащимся постоянно в памяти с меньшей скоростью доступа («основная память»). Кэширование применяется ЦПУ, жёсткими дисками, браузерами, веб-серверами, службами DNS и WINS.

Вопрос со звёздочкой. Какие уровни кеша существуют в вебе? 

Есть пять уровней кэша:

Клиентские

Ускорение получения веб-контента от веб-сайтов (браузеры или устройства)

DNS

Определение IP-адреса для домена

Интернет

Ускорение получения веб-контента от серверов веб-приложений Управление веб-сеансами (на стороне сервера)

Приложение

Повышение производительности приложений и ускорение доступа к данным

База данных

Сокращение задержек, связанных с запросами к базе данных

Что такое https?

HTTPS (аббр. от англ. HyperText Transfer Protocol Secure) — расширение протокола HTTP для поддержки шифрования в целях повышения безопасности. Данные в протоколе HTTPS передаются поверх криптографических протоколов TLS или устаревшего в 2015 году SSL. В отличие от HTTP с TCP-портом 80, для HTTPS по умолчанию используется TCP-порт 443.

Протокол был разработан компанией Netscape Communications для браузера Netscape Navigator в 1994 году.

(далее…)

Стоимость владения кодом

Стоимость владения

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

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

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

Изображение с rawpixel.com

Как сделать узкоспециализированную задачу в приемлемые сроки.

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

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

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

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

Пять признаков проекта, который провалится

Подавляющее большинство проектов проваливается. Понять, что данный проект провалится, не очень сложно. Есть несколько маячков.

Дедлайн спущен сверху

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

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

Чаще же она привязывается к старту какой-нибудь маркетинговой активности или ещё какой-нибудь ереси из мира высокого начальства. У РМ-а же, как правило, возможности отказаться делать проект к данной дате нет и приходится выкручиваться.

Я делал такие проекты. Приходилось подключать дополнительные ресурсы, максимально упрощать фичи, экономить на качестве. Как правило, это приводило к тому, что проект был либо сдан вовремя, либо с небольшим опозданием, однако пользоваться продуктом было невозможно из-за багов и наступали «вторые 90 % проекта», когда попеременно наши тестировщики и приёмщики заказчика шлют баги, а разработчики их мужественно правят.

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

Планируют и реализуют разные люди или даже подразделения

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

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

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

Руководитель проекта недостаточно квалифицирован или мотивирован

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

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

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

Не определились с особенностями реализации проекта

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

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

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

Не определены специфические критерии успешности проекта

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

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

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

Full Stack разработчик, что надо уметь

Сейчас фуллстеками называют себя все подряд. На самом деле, фуллстек должен иметь следующий набор компетенций: