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

Краткость

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

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

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

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

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

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

Постоянство

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

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

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

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

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

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

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

Нет.

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

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

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

Еще вопросы

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

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

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

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

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

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

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

Выводы

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

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

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

Книга рассказывает детальную историю Карибского кризиса (см. википедию). Несмотря на адское название, «Риск» практически не содержит воды — вы прочтете полноценное исследование, со ссылками на архивные документы и публикации.

Книга обязательна всем, чья работа связана с переговорами. Главный урок — предметом переговоров может служить что угодно. К примеру, Хрущев не мог договориться напрямую о снятии ракет на Кубе в обмен на снятие американских ракет в Турции — после таких договоренностей в США просто объявили бы Кеннеди импичмент. Поэтому придумали кучу условий:

• не будет оговариваться расписание демонтажа ракет в Турции;
• демонтаж в Турции начнется не сразу после демонтажа на Кубе, а через несколько месяцев;
• при этом бомбардировщики ИЛ-28, способные перевозить атомные бомбы, останутся на Кубе;
• официальных договоренностей об обмене турецких ракет на советские не будет.

Интересен и формат игры — за все время кризиса никто не обсуждал снятие ракет напрямую. Договоренности строились по несвязанным намекам через самые разные каналы связи — дипломатическую почту, публикации в прессе, выступления на радио и через личные связи. Важный канал был налажен через брата президента — Ричарда Кеннеди, который общался со шпионом ГРУ Георгием Большаковым. Посол СССР в США об этом канале не знал.

Кроме вкуснейшего описания политических игрищ, в книге вы найдете еще много интересного:

• Как шпион КГБ сначала подружился с Фиделем, а потом стал послом СССР на Кубе.
• Почему Кастро и Че Гевара стали коммунистами только после того, как захватили власть.
• Как Кастро не хотел отдавать обратно советские ракеты, а Микоян его успокоил.

Книга изначально написана на английском, но интерес не угасает даже сквозь трудности перевода. Покупайте на Озоне или скачивайте бесплатно, пока не переиздали.

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

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

Эффективность траты денег легко замерить — нужно почитать отчет о прибылях и убытках. Для личных финансов можно взять систему Севы. Рубль потратил, два заработал: чем больше рентабельность, тем больше молодец. А вот у времени рентабельности нет. Оценить эффективность получается только интуитивно: туда ли я иду? приближаюсь ли к долгосрочным целям? что мог сделать лучше за прошлые полгода?

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

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

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

Что почитать по теме:

• Transcend: девять шагов на пути к вечной жизни.
• Арнольд Беннет — Как жить 24 часа в сутки.
• 7 навыков Стивена Кови.

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

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

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

Если рядом с вами программируют хоть что-нибудь сложнее сайта-визитки на вордпрессе — проверьте эти 6 направлений:

• Непрерывная сборка и запуск. Решает проблему с выкатыванием софта — программисту достаточно отправить коммит в репозиторий, дальше все случается без его участия — запускаются тесты, собирается фронтенд, снимаются метрики. Если код в коммите рабочий, продакшн обновляется автоматически. Хороший сервис — CircleCI.
• Замер качества кода. Ключевые метрики — покрытие тестами, сложность, читаемость, наличие копипейста. Хороший сервис — Code Climate.
• Отдельным пунктом — процент покрытия. Это соотношение кода, который выполняется во время прогона тестов к общему количеству кода в приложении. Если у вас проверяется меньше 80%, значит вы пишете плохой код. Если покрытие меньше 50%, а вы работаете над новыми фичами — вы работаете зря. Хороший сервис — Codecov.
• Обработка ошибок. Хранит журнал ошибок и позволяет анализировать продакшн на основе реальных цифр, а не жалоб пользователей. Хороший сервис — Sentry, есть клиенты для всех языков, включая браузерный JS.
• Мониторинг производительности. APM снимет трейсы самых долгих запросов прямо с продакшена, нарисует графики скорости и подскажет узкие места, которые приводят к тормозам. Для каждого фреймворка нужен свой APM, для Джанго я использую Datadog. Еще есть New Relic и куча других.
• Облачный хостинг. Если на вашем проекте есть жужжащая железяка с сисадмином в комплекте — смело избавляйтесь. Дешевле и проще взять ресурсы в аренду и исключить человеческий фактор, чем владеть коробкой, которая не приносит денег. Идите в Azure или хотя бы в Digital Ocean.

Что-то забыл? Пишите в комменты. Интересуетесь автоматизацией? Начните с free-for-dev.