Кручу гайки. Пишу матом. Настраиваю ин-хаус разработку в стартапах.

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

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

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

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

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

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

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

Пацан сказал — пацан сделал

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

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

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

Пацан сказал — пацан сделал

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

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

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

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

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

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

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

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

Давайте не любить новые фичи

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

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

Туду-лист хорошего продуктолога

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

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

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

Менеджер, который любит фичи, превращается в трудолюбивого идиота

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

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

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

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

Нет.

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

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

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

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

Еще вопросы

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

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

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

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

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

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

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

Выводы

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

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

Как корпоративный чат убивает продуктивность

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

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

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

Корпоративный чат — это уведомления

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

Слэк — не первый, так работает фейсбук, Первый канал и Дарья Донцова

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

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

40 загаженных инбоксов

Важнейшее правило ГТД — единственный, периодически очищаемый инбокс. В Слэке такой чистоты не доби­ться — вместо аккуратной папки вхо­дящих в голову лезут десятки каналов. Если вы счастливый не-пользователь Слэка, и не знаете, что такое каналы — почитайте рассказ Медузы.

e-mail vs. skype

В корпоративном Слэке завели 40 комнат для разных предметов обсуж­дения: брифы, редактура, новые статьи, мониторинг соцсетей. Предполагается, что люди читают только те каналы, которые им важны. Угадайте, как проис­ходит на самом деле? Правильно, участники чата постоянно разгребают 40 папок входящих, 5 из которых — с котик­ами, а еще 20 не нужны для работы.

Небрежность

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

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

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

Одна задача — много исполнителей

В психологии есть понятие эффекта свидетеля — когда толпа людей видит нечто плохое, и никто не вмеши­вается, потому что ждет, что вмешается сосед. Эффект свидетеля ожидает вашу задачку в любом чате.

Эффект свидетеля

Хороший менеджер декомпозирует задачи на кусочки. Кусочек задачи — один шаг одного исполнителя. Такие задачи проще сделывать — нет стимула размазывать ответственность («Ой, а дизайнеры не нарисовали», «Ой, тут пусть сисадмины выкатывают»). Декомпозированную задачу на одного исполнителя уже незачем кидать в чат — нафига отвлекать 30 других человек?

Синхронность

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

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

Корпоративный чатик — это восьмичасовое собрание 30 человек без четкой повестки

Кому-то удобнее работать помидорками, кому-то — циклами по 2 часа. Кто-то работает из круглосуточной шоколадницы или живет в Магадане. Это не важно, когда команда общается асинхронно. Чтобы добиваться результатов, достаточно пересекаться на 15 минут раз в пару дней.

Если команда слаженно работает только сидя в одном помещении или комнате чата — что-то не в порядке. Скорее всего ребята не умеют общаться, и пора усилить команду администратором.

Вывод

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

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

Как я подбираю книги

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

1) Не выбираю книги в интернет-магазине

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

Сравните интерес к Дейлу Карнеги и к Михаю Чиксентмихайи, автору самой полезной бизнес-книги, которую я знаю:

Csikszentmihalyi vs Dale Carnegie
Данные Гугль-трендс

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

2) Выбрасываю скучные книги

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

Книги, которые я выбросил в апреле 2016
Книги, которые я выбросил в апреле 2016 г.

От «Организаций будущего» я ожидал описания оргструктур по Друкеру, и бросил, распознав книгу о холакратии — организации без менеджеров, которую безуспешно пытался внедрить Тони Шей в Запосе. «Чеклист» Атула Гаванде я выбросил после пассажа о том, как автор, управляя Боингом-777 «переключился на нейтраль и стал ждать очереди на взлет».

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

Итого

  1. Покупайте книги только из зарекомендовавших себя источников;
  2. Если книга не прет — не стесняйтесь выбрасывать.

Главное дело

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

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

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

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

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

Чтобы системно делать обзоры, поставь периодическую задачу и не берись ни за что другоге, пока не закончил обзор. Серьезно, если не поставишь задачу — обзоров не будет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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