Федор Борщев

Планирование спринта: буфер

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

Самое главное правило — не обманывать себя при планировании и помнить, что планы без запаса не сбываются.

Свой запас я держу в буфере, который называется «можно проебать» — это прям такой лейбл в трекере. Лейбл ставится на задачи, которые мы будем делать только, если успеем закончить более важные.

Прямо в трекере написано, что задача — буферная

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

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

Тупое правило про 50%

Ещё в студии я познакомился с простым правилом управления любым проектом:

Если прошло 50% времени, проверь — выполнена ли половина работы

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

Нарушенное правило 50 процентов

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

Кстати, вопрос про 50% можно задавать самому себе и без помощи менеджера — хватит даже самой простой системы напоминалок.

Топ-даун и прогрессивный джипег для программистов

Правило Парето гласит, что 80% времени программиста тратится на 20% требований. К примеру, на любом современном фронтенд-фреймворке работающую корзину в интернет-магазине можно запилить за день — можно будет добавить/удалить товар и отправить заказ.

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

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

Инженеры называют этот подход top-down, дизайнеры — прогрессивным джипегом.

Проверь через два дня

Многим программистам (и менеджерам) не хватает простого навыка — проверить через два дня.

  • Сделал кнопку — проверь через два дня, нажимают ли ее вообще? Что видят, когда нажали?
  • Сделал интеграцию — проверь через два дня, сколько пришло данных? Пришли ли вообще?
  • Сделал новое уведомление — проверь логи. Что уходит пользователям? А много вообще ушло?

Проверка через два дня не требует никакого напряжения и предотвращает кучу долга — в проекте не копятся неработающие и невнедренные фичи.

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

Кто должен проверять через два дня, если задачу делали впятером? Конечно ты.

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

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

Краткость

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

В проектном плане — одно предложение для одной задачи

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

Проверяемость

Каждый пункт плана содержит глагол в совершенной форме и обещает что-нибудь сделать:

Обещание Хуйня
Сделаем Будем делать
Починим Посмотрим
Доработаем Приступим к доработкам
Назовем сроки Начнем

Я сделяль проектный план

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

  • Починили отправку СМС, вот скриншоты с телефона;
  • Сделали отчет по пропущенным звонкам, файл во вложении;
  • Избавились от падений сервера, вот график мониторинга.

Постоянство

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

Если хоть один понедельник проебался — проект разваливается. Хочешь отдохнуть — запланируй поменьше дел, но не пропускай понедельник*.

Потратить 10 минут на еженедельный план легче, чем не съесть тортик в кофейне

Писать письма по понедельникам — не больно. Весь процесс планирования и рефлексии занимает не больше 10 минут — не съесть тортик, проходя мимо кофейни, сложнее, чем написать хороший план. И уж точно 10 минут стоят спокойной и результативной недели.

Вместо выводов

  1. Короткий и проверяемый план сжигает мосты и мотивирует. Все просто — если план не выполнен, то я плохой менеджер: дал конкретные обещания и сам же их проебал.
  2. Постоянная и публичная проверка выполнения плана держит команду в тонусе, а пульс проекта — в ритме 52 отгрузки в год.

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

Небольшие доработочки

«А давайте ограничим длину обзора до 140 символов? Ну, вдруг мы захотим их в СМС рассылать, да и вообще нечего перегружать людей длинными обзорами. Это же 5 минут всего?».

Нет.

Большинство кодеров с вашей работы оценит эту задачу в 5 минут — чего там, надо только атрибут maxlength добавить. Но если вы — менеджер, который борется за качество своего продукта, то все гораздо сложнее.

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

Что будет, если пользователь отправил обзор длиннее 140 символов? Просто обрежем, или покажем сообщение об ошибке? Если сообщение об ошибке, то где? Что напишем в сообщении? Нужен ли копирайтер? Сможем ли мы доступно объяснить пользователям, что нельзя отправлять больше 140 символов? Есть ли у нас в гайдах стили для таких ошибок? Нет? А кто нарисует?

Ворд целиком состоит из небольших доработочек
Ворд целиком состоит из небольших доработочек

Еще вопросы

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

Есть ли свободные фронтендеры? Должно ли сообщение об ошибке повторять текст, который мы написали для сервера? Если нет, то кто напишет новое сообщение? Как нам сделать, чтобы в будущем любое изменение к «правилу 140» внедрялось одновременно и на сервере, и на клиенте?

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

Счетчик символов

Кто запилит счетчик? Кто проверит работоспособность на IE9 (вдруг мы — сайт банка)? Где мы его расположим? Как он будет выглядеть? Есть ли свободные дизайнеры?

Наверное внешний вид должен меняться по мере приближения к 140 символам. Ой, а что мы будем делать, когда пользователь упрется в лимит? Перестанем принимать ввод? А что делать, если пользователь вставит длинную портянку из буфера обмена? Разрешить обрезать текст или выдать ошибку?

А как мы объясним посетителям, что раньше было можно писать длинные обзоры, а теперь нельзя? Наверное, нужно научить саппорт отвечать на такие вопросы. А еще нужно обновить API и оба мобильных приложения. А что делать с уже написанными обзорами? Обрезать до 140 символов? Если обрезать, то по границе слов или предложений? А что, если граница предложения будет намного больше 140 символов?

Выводы

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

Эта заметка написана по мотивам поста из блога компании Интерком. Я сделал перевод, чтобы повысить вероятность того, что этот текст осилит менеджер занятый пропихиванием жизненно важной фичи в релиз.

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

Что глупого можно сделать, когда опаздываешь на встречу? Предупредить об опоздании за пять минут до начала. А еще глупее? Пообещать прийти через 10 минут, а прийти через 20 — опоздаешь дважды.

Когда я опаздываю, я волнуюсь. А когда я взволнован, я неверно воспринимаю реальность — переоцениваю свои силы и называю заниженные сроки. В новые сроки невозможно уложиться, и все повторяется по кругу — доверие разваливается вместе с проектом.

Но я же

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

Ошибиться со сроком — не страшно. Страшно — ошибиться второй раз: тебе перестанут доверять.

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

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

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

Длинные ТЗ не работают

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

От этих монументальных документов никто потом не отклонялся — в плановой экономике нет конкуренции, можно выпускать одни и те же жигули хоть 30 лет подряд.

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

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

Чтобы запустить интернет-магазин, не обязательно продумывать 20 состояний корзины. Разбейте проект на короткие итерации и концентрируйте усилия только на текущей:

  • Концептуальная страница-заглушка с телефоном
  • Страница с контактами и десятком самых продаваемых товаров
  • Каталог товаров, «купить в один клик»
  • Корзина
  • Синхронизация с црм, 1с

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

Как ставить результативные задачи

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

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

Дизайнерам тяжелее, чем стоматологам. Вместо желаемого результата им часто присылают неумело описанный процесс: «хочу сверху фоточку чайника, ниже список цветов и объемов, потом неяркий блок с дополнительными товарами и синюю кнопку «купить» (чтобы в первый экран влезала!)».

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

Ставьте задачу дизайнеру, как стоматологу — не лезьте в процесс. Описывайте желаемый результат:

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

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

Постановке результативных задач стоит поучиться у Бюро Горбунова:

  • Совет, как писать ТЗ на сайт.
  • Настоящая задача для «Додо пиццы».
  • Настоящая задача для «Регуляра».

Проектный план и диаграмма Ганта

Диаграмма Ганта — популярный инструмент планирования: на ней основан богомерзкий МС-Проджект, она используется в методе критической цепи и ПМБоКе. Если вы запланируете простейшее действие, скажем поклеить дома обои, и нанесете на календарь последовательность операций (сходить в магазин, вынести мебель), то у вас получится диаграмма Ганта.

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

Диаграмма Ганта

Внешний вид диаграммы Ганта, слева этапы, справа — календарное представление

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

Диаграмма Ганта Проектный план
Мы находимся на восьмом дне этапа прикрутки макетов. Этап закончится через 7 дней Завтра ты получишь от дизайнера макет, сдача в четверг, значит первый подход нужно закончить во вторник
В пятницу заканчиваем бета-тестирование Закрой до пятницы 20 оставшихся багов
Через день должно закончиться согласование Позвони клиенту и поинтересуйся, почему он уже два дня молчит

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

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

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