Заметки с тегом «Проекты»

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

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

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

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

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

Во всех своих командах я избавляюсь от срочных задач. Люблю, когда даже в трекере такого флага нет.

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

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

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

Вот вам три шага, чтобы победить срочные задачи в вашей команде:

• Разберитесь с техническими и управленческими долгами. Чаще всего срочные задачи возникают на уровне «я выкатил, а оно упало», и «я выкатил, а через неделю поняли, что нихуя не работает». Чтобы привести долги в порядок, нужна сила воли и пара месяцев. Если вы понимаете, что за два месяца не разберетесь — значит что-то в вашем проекте серьезно не в порядке, нужно все бросать и лечить.
• Перестаньте оценивать задачи в часах. Если в вашей команде меньше 5 человек — совсем не оценивайте. Если больше, и план на неделю не удается обсудить с каждым лично — попробуйте оценивать днями.
• Возьмите комфортный интервал планирования, на который вы можете построить четкий план, к примеру 1 неделю. Заложите запас и не трогайте ребят в течение этого интервала.

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

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

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

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

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

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

Давайте экономить деньги и не любить фичи.

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

Краткость

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

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

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

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

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

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

Постоянство

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

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

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

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

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

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

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

Нет.

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

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

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

Еще вопросы

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

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

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

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

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

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

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

Выводы

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

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