Виктор Палыч Говоров — Антибиотик, х/ф «Бандитский Петербург»

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

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

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

Казалось бы, в настоящих системах сотни и тысячи мест, за которыми нужен присмотр, — это невозможно охватить! Но принцип «всё смотрю» не следует понимать буквально. Речь о том, что хороший руководитель так всё организовывает, что эффект получается такой, будто он действительно смотрит всё. А делает он это с помощью трёх компонентов: 1) метрик, 2) удобного интерфейса доступа к метрикам, 3) ритмичной проверки.

Метрики: за чем смотрим

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

«Король сырков» Б. Ю. Александров следит за цехами, рабочими, процессами, чистотой, качеством, выкладкой в магазинах. И это только то, что показано в интервью (2:55):

Виктор Палыч Говоров по кличке Антибиотик довольствуется ежевечерним докладом (0:50):

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

Чтобы «всё смотреть», метрику нужно выбрать одну — ту, по которой отслеживается главная ценность продукта. Остальные метрики — дополнительные

Интерфейс: как смотрим

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

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

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

Маркетинговый дашборд из лекции Алексея Куличевского

О гугль-таблицах из лекции Алексея: «У каждого из вас к ним есть доступ, не нужно никакой специальной регистрации, не нужно ничего устанавливать. Гугль‑таблицам всё равно, на какой системе вы работаете. И они могут делать почти всё, что может делать специализированный софт».

P&L «Додо-пиццы». У «Додо-пиццы» отчёт о прибылях и убытках публичный. Любой франчайзи или инвестор может следить, как идут дела в его пиццерии или у соседа. В таблице видно, сколько денег приносит доставка и ресторан, детально описаны операционные расходы и автоматически считается EBITDA:

Отчёт о прибылях и убытках партнёрских пиццерий «Додо-пиццы»

Набор дашбордов Дарьи Мингалиевой. В давней статье на «Виси» Дарья предлагает создать таблички с план-фактом по компании в целом, маркетингу, продажам, продукту и финансам — такой минимальный набор метрик для руководителей.

Перформанс-дашборд из статьи «Как систематизировать маркетинг»

В этой статье нет модных дашбордов с графиками и диаграммами — только гугль-таблицы. Ещё примеры:

Таблица личного бюджета. Шаблон и инструкция в Т—Ж

Таблица для отслеживания акций. Инструкция и шаблон в Т—Ж

Таблица учёта личного рабочего времени. Инструкция и шаблон в Т—Ж

Таблица семейного бюджета

Конечно, далеко не все используют гугль-таблицы для доступа к метрикам, поэтому тупое правило будет таким:

Чтобы «всё смотреть», интерфейс доступа к метрикам должен быть не сложнее гугль-таблицы. Или прямо гугль-таблицей

Ритм: как часто смотрим

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

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

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

Еженедельные встречи в «Эпле». Стив Джобс рассказывает, что в «Эпле» основные топы собираются раз в неделю и разговаривают три часа:

Еженедельное ревью в ГТД. В методологии личной продуктивности Дэвида Аллена сказано, что еженедельный обзор — ключевой фактор успеха (Critical Success Factor). Для тех, кто пользуется системой, есть специальный шаблон:

Недельный обзор из методологии ГТД

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

Если свести всё к очередному тупому правилу:

Чтобы «всё смотреть», метрики нужно проверять раз в неделю

Итого

Руководитель должен «всё смотреть». Для этого, если свести всё к тупым правилам, нужно 1) определить ключевую метрику, 2) организовать к ней доступ в гугль-таблице и 3) проверять раз в неделю.

Проект — это путешествие из точки А в точку Б, полное неожиданностей и приключений. Это знает любой, кто знаком с ФФФ.

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

• Без дедлайна × 5
• Фичеризм × 4
• Старение × 3
• Раздувание бюджета × 3
• Неграмотная замена исполнителя × 2
• Переусложнение × 2
• Без флекса × 2
• Безответственное делегирование × 2
• Закармливание проблем × 2
• Нужда × 2
• Планирование впритык × 2
• Переобещание × 1
• Жертва качеством × 1
• Неопытность × 1
• Отрицание проблем × 1
• Недостаток ресурсов × 1
• Слабая команда × 1
• Спонтанные решения × 1
• Косность × 1
• Грубая сила × 1
• Всё сразу × 1
• Мало управления × 1

Редизайн сайта «Тинипайлот»

Майкл Линч заказал у агентства редизайн сайта для своего бизнеса. Предприниматель рассчитывал уложиться в 4 недели и 15 тысяч долларов — проект растянулся на 8 месяцев и обошёлся в 46 тысяч.

Без дедлайна. Майкл не договорился с агентством о сроках. На вопрос о том, сколько продлится редизайн, он услышал: “How long is a piece of string?” («А какова длина у нити?»). Главный дизайнер дал понять, что всё зависит от скорости согласований: можно утвердить первый же прототип, а можно перебирать варианты неделями. Предварительно задачу оценили в 30—40 рабочих часов — это от двух до четырёх недель. Но с оговоркой: могут возникнуть задержки, потому что в приоритете — более крупные долгосрочные проекты с фиксированной предоплатой. Майкл согласился подождать лишние пару недель, если понадобится.

Проект стартовал в сентябре — концепцию фирстиля утвердили только через 6 недель. К декабрю логотип выполнили на 95%, сайт был ещё не готов. После этого работа встала на паузу — её возобновили только в марте и закончили в первых числах июня.

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

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

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

Раздувание бюджета. Майкл платил за часы работы, а не за результат — задачи буксовали, а траты росли. Так, его убедили, что на сайте нужно заменить старую тему «Бутстрапа»: новый дизайн плохо с ней сочетался. Обещали сделать за неделю — потратили пять, и стоило это 6 тысяч долларов. В результате таких доработок стоимость проекта выросла с 15 тысяч долларов до 46 тысяч.

Закармливание проблем. Спустя полгода работы агентство предложило перейти от почасовки к ежемесячной фиксированной предоплате. Предупредили: выйдет дороже, но быстрее. Команда начнет бронировать под проект 60 часов в месяц и перестанет отвлекаться на других клиентов. Работы оставалось всего на 20 часов, но Майкл согласился оплачивать 60. Чтобы израсходовать всё забронированное время, он заказал у агентства разработку в дополнение к дизайну.

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

Мало управления. Агентство не выделило менеджера на проект, причём это решение было принято без Майкла. Роль менеджера отчасти выполнял CEO агентства, отчасти — главный дизайнер, но никто из них глубоко не погружался в управление. Некому было следить за сроками, распределять и флексить задачи, сообщать заказчику статус. Сам он не мог контролировать, чем занимается команда.

«Киберпанк 2077»

Студия «СД Проджект Ред» задумала выпустить приключенческую ролевую игру «Киберпанк 2077». Её ждали 8 лет. Выручка от предзаказов превысила затраты на разработку и рекламу. После релиза — баги и неоднозначные реакции игроков.

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

Спустя годы в трейлере показали главного героя Ви в действии и изящные ретрофутуристические эффекты. Вдобавок к проекту привлекли знаменитостей: Киану Ривза и рэпера АСАП Роки.

Летом 2020 года на Ютубе стартовало шоу, каждый эпизод которого был посвящен какому-то аспекту мира «Киберпанк 2077». СМИ хвалили превью за сюжет и детализацию.

Стараниями пиарщиков «Киберпанк 2077» не раз возглавлял рейтинги самых ожидаемых игр.

Без дедлайна. «Киберпанк 2077» анонсировали в 2012 году, но не назвали дату выпуска. Первые 6 лет новостей о проекте было мало, разработчик переключился на другую свою игру — «Ведьмак». В 2019 году релиз наметили на 16 апреля 2020-го. Позже его перенесли на 17 сентября, затем на 19 ноября и, наконец, на 10 декабря 2020 года.

Без флекса. До первоначальной даты запуска оставалось три месяца. «СД Проджект Ред» заявили: скорее всего, команде придётся работать сверхурочно, чтобы успеть к дедлайну. И всё же релиз перенесли на 9 месяцев: игра нуждалась в доработке. Перед ноябрьским дедлайном история повторилась: разработчики трудятся по 6 дней в неделю и не успевают.

Жертва качеством. Перед релизом было очевидно, что игра плохо идёт на консолях Плейстейшн 4 и 5 и на новых устройствах Иксбокс. «СД Проджект Ред» пыталась на скорую руку всё исправить и к релизу выбрала лучшую из версий «Киберпанка 2077». Это не решило проблему — геймеры стали жаловаться на баги. Возмущённые клиенты магазина «Плейстейшн Стор» обрушили сайт «Сони», и компания отозвала «Киберпанк 2077» из продажи. То же сделали и в «СД Проджект Ред», пообещав вернуть деньги недовольным покупателям.

«Русские горки» в Сочи

В Сочи к зимней Олимпиаде-2014 начали возводить комплекс трамплинов «Русские горки». Строительство затянулось и подорожало почти в 7 раз.

Без дедлайна. Возводить «Русские горки» начали в 2008 году, сдать комплекс планировали в июне 2011-го. В декабре 2011 года завершился только первый этап строительства: исполнитель — основной акционер ОАО «Красная Поляна» — сорвал сроки. После этого в 2012 году проект (вместе с основным пакетом акций «Красной Поляны») перешёл к Сбербанку. Он достроил «Русские горки», и комплекс ввели в эксплуатацию в сентябре 2013 года.

Раздувание бюджета. На старте проект оценивался в 1,2 млрд рублей. Двухлетняя задержка при строительстве увеличила затраты до 8 млрд рублей.

«Тобиас и тёмные скипетры»

14-летний Адам Бутчер решил создать эпическую онлайн-игру «Тобиас и тёмные скипетры» на основе MMF. Когда игра была готова, парню уже исполнилось 26.

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

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

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

Без флекса. Тобиас должен был побороть зло за 13 уровней, и автор игры добросовестно следовал этому плану. Он даже не думал, что можно сократить несколько подземелий и закончить работу быстрее.

Нужда. Адам не мог бросить игру: слишком много вложил сил и времени. Казалось, сдаваться уже поздно, ещё чуть-чуть — и всё готово. Естественно, «чуть-чуть» длилось годами.

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

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

Аэропорт Берлин-Бранденбург

В 1990-х Берлину понадобился новый международный аэропорт. Крупный транспортный хаб должен был заменить три устаревших воздушных гавани. Проект готовили 16 лет, стройка шла 14. Открытие аэропорта откладывали 5 раз.

Стройка международного аэропорта Берлин-Бранденбург в апреле 2011 года — за полгода до дедлайна. Фото ДПА / Алами / Вида Пресс

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

Фичеризм. В 2000-х аэропорт укрупняли ещё до начала строительства: добавляли всё новые гейты и в итоге получили дополнительный этаж. Плюс мэр Берлина потребовал, чтобы аэропорт мог принимать аэробусы А380, — многое пришлось по-быстрому переделывать.

Без дедлайна. Авиагавань начали возводить в 2006 году. Весной 2010-го стройка имела мало общего с изначальным планом и вдобавок была далека от завершения. Открытие аэропорта перенесли с ноября 2011 года на июнь 2012-го, а потом отложили опять. В 2013 году сроки сорвали дважды, дедлайн переместился на 2017-й. В конце концов аэропорт заработал в 2020-м.

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

Отрицание проблем. Весной 2012 года было очевидно, что работу не закончат к очередному дедлайну — 3 июня. При этом руководители проекта делали вид, будто проблемы нет. Министры наведывались на стройку — им пускали пыль в глаза. Власти готовились 24 мая праздновать открытие авиагавани с участием канцлера ФРГ. В дьюти-фри уже расставляли товары на полках. Что аэропорт не готов, объявили только 7 мая.

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

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

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

Раздувание бюджета. За время строительства стоимость проекта утроилась и превысила 7 млрд евро.

Проект «Занаду»

Философ и социолог Тед Нельсон в прошлом веке придумал «Занаду» — глобальную систему поиска и хранения текста. В «Занаду» фундаментальная единица — документ с «окнами» в другие документы. В процессе пользования появляются новые связи и «окна» — система разрастается. Тед Нельсон мечтал с помощью «Занаду» открыть моментальный доступ к любому литературному произведению или его фрагменту. Проект разрабатывался 54 года.

Опубликованная в 2014 году версия «Оупен Занаду»

Недостаток ресурсов. В 1960-х «Занаду» опережала развитие технологий, поэтому было трудно найти достаточно мощные компьютеры для неё. С финансированием тоже были проблемы. Нельсон постоянно искал инвесторов: сначала — чтобы запустить проект, со временем — чтобы удержать его на плаву. В 1980-х его группа оказалась на грани банкротства. Тогда компания «Аутодеск» заинтересовалась проектом, выкупила «Занаду» и начала спонсировать. Через 5 лет «Аутодеск» потратила 5 млн долларов и не получила результата — лицензию для работы над «Занаду» приобрела фирма «Мемекс». После финансовых трудностей и эта компания отказалась от проекта. Тогда японские университеты пригласили Нельсона в свои лаборатории.

Без дедлайна. Поначалу Тед Нельсон экспериментировал с гипертекстом на небольших проектах, затем начал разрабатывать «Занаду» в Гарвардском университете. Автор системы уверял, что она будет готова в 1976 году. К 1979-му были реализованы только отдельные элементы «Занаду». Затем он объявил новый дедлайн — 1988 год — и провалил его. Спустя 10 лет Нельсон выпустил лишь исходный код для «Занаду».

Проект завершился в 2014 году: частично рабочая версия системы «Оупен Занаду» была опубликована.

Фичеризм. «Занаду» была технически сложным надсистемным проектом. Нельсон не раз пересматривал систему, перепроектировал целиком и по частям.

Неграмотная замена исполнителя. За 54 года в проекте «Занаду» поработали разные программисты. Состав команды сменился в 1971 году. Через 8 лет Тед Нельсон набрал новых людей, потому что решил всё полностью переделать.

В 1980-х вдобавок к группе разработчика Роджера Грегори была нанята ещё одна команда. На тот момент программное обеспечение «Занаду» было написано на языке Си и работало не так, как ожидалось. Новые программисты стали переписывать ПО на Смолтоке. Дедлайн сорвали, коллектив раскололся. Позже из-за нехватки финансирования часть программистов вообще ушла, прихватив свои компьютеры.

Старение. Пока создавалась «Занаду», Тим Бернерс-Ли изобрел язык ХТМЛ и (при участии Роберта Кайо) Всемирную паутину. Так родился современный веб, основанный на страницах и гиперссылках. Хотя Тед Нельсон предложил идею гипертекста, он не успел воплотить её первым. А когда воплотил, мир уже 25 лет как жил с вебом.

Экспедиция Скотта в Антарктику

В 1910 году Роберт Скотт возглавил британскую экспедицию в Антарктику. Её участники должны были первыми достичь Южного полюса, где до тех пор не ступала нога человека. Однако их опередили норвежцы под руководством Руаля Амундсена. Команда Амундсена за 99 дней добралась до полюса и обратно на базу, а затем благополучно вернулась домой. Скотт с четырьмя товарищами провели в пути 150 дней и погибли от холода, голода и изнеможения.

Диаграмма экспедиций Амундсена и Скотта

Переусложнение. Скотт отплыл в Антарктику на барке «Терра Нова» с командой из 65 человек, среди которых были офицеры и матросы, два кочегара, 12 учёных, кинофотооператор, специалист по пони, норвежский специалист-лыжник, русский конюх Антон и отвечавший за собак Дмитрий. Для передвижения в снегах британцы везли трое моторизованных саней, 33 собак и 19 пони, которым, естественно, требовались тонны фуража.

Безответственное делегирование. Высадка при большом количестве людей и поклажи осложнялась тем, что Скотт не продумал детально план. Сам он вышел на берег и оставил Виктора Кэмпбелла руководить процессом. Чтобы перевезти груз с «Терра Новы», задействовали все виды транспорта. Возникла неразбериха. В итоге одни мотосани проломили лёд у корабля и затонули, едва не утянув на дно нескольких человек.

Планирование впритык. При планировании четырёхмесячного путешествия Скотт не оставил про запас и нескольких дней на случай непогоды. А непогода в Антарктике случается часто. Скотт постоянно повторял: «Мы не можем позволить себе задержку». Любое промедление означало впоследствии нехватку провизии и горючего, ведь всего было впритык.

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

Слабая команда. Из 65 человек на борту «Терра Новы» только 14 ранее участвовали в полярных экспедициях Роберта Скотта и Эрнеста Шеклтона. Многие не умели ходить на лыжах, и после высадки в Антарктике их обучал этому норвежский эксперт.

Для похода к полюсу Скотт выбрал четырёх спутников: кавалериста Лоуренса Отса, квартирмейстера Эдгара Эванса, моряка Генри Бауэрса и врача Эдварда Уилсона. Трое, включая самого Скотта, имели опыт полярных экспедиций. В отличие от них Отс попал на «Терра Нову» потому, что был ценным специалистом по пони и внёс в фонд экспедиции 1000 фунтов. Бауэрс до этого служил в индийском флоте и был заочно принят в команду Скотта по рекомендации экс-президента Королевского географического общества.

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

Спонтанные решения. К полюсу должны были идти четверо, но Скотт в последнюю минуту изменил решение и взял пятым Бауэрса. При этом количество провизии и снаряжения, в том числе лыж, было рассчитано на четверых.

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

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

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

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

Тем временем норвежцы в проветриваемых меховых анораках стремительно приближались к полюсу на лыжах и собаках.

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

Команда

Николай Товеровский — автор,
Полина Лукьянович — редактор.

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

Чтобы расти эффективно, найдите наставника, который направит, поможет составить план роста и не даст его провалить. Такой наставник — «шеф». Шеф — не покровитель. Если у подшефного возникает проблема, шеф подсказывает, как её решить, но не решает её сам.

Найти шефа сложно, поэтому я запустил услугу «Посоветоваться с шефом».

Услуга «Посоветоваться с шефом»

Представляю услугу «Посоветоваться с шефом». Работает так:

1. Договариваемся с вами о встречах.
2. На встрече созваниваемся по скайпу, обсуждаем направление роста и придумываем, как вам в этом направлении двигаться, какие задания выполнить, что прочитать, куда сходить, с кем поговорить.
3. ???????
4. ПРОФИТ.

Запланировать встречу

Ответы на вопросы

В каких направлениях роста вы можете помочь?

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

Как часто проходят встречи?

Чаще раза в две недели бессмысленно. Рост — это самостоятельная работа. Шеф только помогает выбрать направление, скорректировать движение и не забить.

Когда будут встречи?

В субботу или воскресенье утром. Другое время — можно обсудить.

А можно в офлайне встречаться?

Сорри, нет. Я иногда куда-нибудь уезжаю, и встречи в офлайне слишком негибкий формат.

Сколько встреч нужно?

Сколько хотите. Для пинка может хватить и одной. В бюро рост бесконечный — пока ты в компании, ты растёшь с шефом.

Какие гарантии моего профессионального роста вы даёте?

Никаких. Ваш рост — это ваша работа, я могу только немного помочь.

Зачем всё это самому шефу?

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

Ху из мистер шеф?

Меня зовут Николаем Товеровским. С 2009 года я работаю с Дизайн-бюро Артёма Горбунова, несколько проектов для примера: Раз-два-трип, Журнал «Главбух», Диаграмма экспедиций Амундсена и Скотта.

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

Помог «Додо Пицце» сделать: американский сайт, промостраницу франшизы, внутреннюю базу знаний, сайт «Одного миллиарда».

В DRIVE2.RU запустил: мобильный сайт и приложения, новые «Бизнес-акаунты».

Занимаюсь собственными проектами: сайт ФФФ.воркс, Осьминожка навыков, Конспект.

Выгляжу примерно так:

Фото автора из книги «Управление проектами, людьми и собой»

Отзывы

Анатолий Буров

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

Ещё Коля делится кучей разных конкретных и обобщённых примеров и даёт практические советы. Определить принципы руководства. Составить шаблоны типовых задач. Не эскалировать проблемы без крайней необходимости.

Конечно, большинство этих штук уже есть в книжках. Моя проблема в том, что погребённые под слоями пассивного знания нужные идеи вовремя не всплывают. Спасибо Коле, что помогает их вытащить на свет.
Дополнительно вдохновляет невероятное спокойствие и осознанность Коли. Это какой-то особый скилл: сохранять равновесие в любых ситуациях. Вдохновляет даже просто наблюдение за этим со стороны».

Анатолий Микалюк

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

Вадим Юмадилов

«Ты научил меня подходам „Делать не значит сделать“, „Можно всё“ и „ФФФ“. Сначала в статьях на ЖЖ, потом в совместных проектах. Теперь это моя прошивка и я автоматически применяю метод, если он нужен».

Николай Товеровский — автор курса и книги об управлении проектами
https://bureau.ru/projects/book-fff/,

Марсель Зиганшин — совладелец пиццерии Бизон и бывший топ-менеджер Додо Пиццы
http://bizonpizza.ru,

и Вадим Юмадилов — дизайнер и любитель нездоровой пищи
http://www.fuckgrechka.ru/tzlvt/

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

Мы специально подобрали участников так, чтобы было интересно. Николай всю жизнь работает в компаниях. Марсель был бизнес-консультантом в Москве, потом уехал работать в офисе Додо Пиццы в Сыктывкаре, а сейчас запустил свой бизнес. Вадим и делал свои проекты, например, антикафе с оборотом 450 000 в месяц, и работал в компаниях.

Николай Товеровский — автор курса и книги об управлении проектами, людми и собой
https://bureau.ru/projects/book-fff/,

Вадим Юмадилов — автор приложения «Тяжеловато»
http://www.fuckgrechka.ru/tzlvt/,

и Иван Сурвилло — молодой журналист и редактор
http://sourvillo.ru

поговорили о высшем образовании и порубились в Мортал Комбат Икс:

В электронном учебнике «Управление проектами, людьми и собой» вышла новая игра! Учитесь рулить проектом, не рискуя настоящими деньгами и репутацией. Смотрите видео и попробуйте сыграть лучше, чем Николай Товеровский:

Игра работает без подписки на книгу — ищите её в демоглаве:
https://bureau.ru/books/fff/demo/17

Чтобы играть лучше, подпишитесь на книгу:
https://bureau.ru/projects/book-fff/

Поздравляем Илона Маска с запуском Фалькона Хеви. Если будем переиздавать книгу по управлению, с удовольствием закрасим новые ракеты в главе о маршруте проекта:

Разворот из книги «Управление проектами, людьми и собой»

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

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

Для построения маршрута проекта используйте принцип „думать глобально, действовать локально“.

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

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

Roald Amundsen. My Life as an Explorer

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

Тут он в полной мере оценил то, что наблюдал во время миграции нетсиликов. Кого-то из эскимосов посылали бежать впереди собак, чтобы раззадоривать их. Причина была очевидна — даже обученные собаки не любили устремляться в пустоту (чувствительные натуры, что и говорить). В прошлый раз это не так бросалось в глаза благодаря благоприятной обстановке и таланту Хелмера Ханссена. Теперь ситуацию надо было спасать. И Амундсен быстро принял единственно правильное решение. Он пошёл впереди, в авангарде, а собаки побежали за ним по пятам, Ристведт следовал позади. «Это было чрезвычайно изнурительно», — написал Амундсен в конце дня, не забыв упрекнуть себя в том, что они прошли всего десять миль. Увы, перфекционисты крайне редко признают собственные достижения.

Роланд Хантфорд. Покорение Южного полюса. Гонка лидеров. Манн, Иванов и Фербер, 2012

Лидерство — это работа. От лидера в первую очередь зависит успех проекта. Лидер «тащит» проект, и его работа «затащить» не смотря ни на что.

Основные ножки «осьминожки» лидера: репутация, видение, решение проблем, сделать, делегирование. Чем больше у лидера слотов для подключения других осьминожек, тем лучше.

Репутация

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

Репутация — капитал лидера. Начиная проект он вкладывает в него свою репутацию. Если проект получается успешным, репутация лидера растёт, он получает дивиденды. Если проект проваливается, репутация лидера снижается. Если репутация станет отрицательной, она не только не будет помогать лидеру, но и станет мешать: «с ним больше работать не будем».

Существует несколько способов заработать репутацию:

Результат. Если лидер добивается успеха, его репутация растёт. Поражения снижают репутацию. «Дон теряет хватку», — говорят подельники мафиозного босса.

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

Харизма. Энергия, вера в победу повышает репутацию. Люди готовы идти за харизматичным лидером, перенося поражения и невзгоды.

Сила. Сильные решения поднимают репутацию лидера. Особенно, если они принимаются в тяжёлых условиях. Заявление Сталина «Я солдата на фельдмаршала не меняю», видимо, выдумка, но звучит сильно.

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

Видение

Работа лидера иметь видение и транслировать команде. Лидер идёт впереди и ведёт проект за собой. Он должен смотреть и видеть дальше всех.

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

Решение проблем

Сложности возникают в любой работе. Лидеру по определению достаются самые нерешаемые и сложные проблемы.

Проблемы можно грубо разделить на технические и человеческие. Решить технические проблемы помогает теория решения изобретательских задач (ТРИЗ).

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

Сделать

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

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

Делегирование

Второй наиболее часто используемый навык лидера — делегирование — достоин отдельного рассказа.

P. S.

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

1. То, что вы храните достаточно долго, можно выбросить.
2. Как только вы что-то выбросите, оно вам понадобится.

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

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

Тщательно выбирайте людей в команду до старта проекта, как это делал полярный исследователь Руаль Амундсен:

Один лоцман сказал, что корабль Амундсена — это самое поразительное из всего, что он видел. «Приказов не отдавали, но все, казалось, точно знали, что нужно делать».

Хелмер Ханссен писал, что он «попал не к строгому капитану, не к начальнику, а будто бы к отцу».

Не все знавшие Амундсена чувствовали это, но он старался всегда делать правильный выбор. И никогда не позволял эмоциям влиять на свои решения. Рассказывают, как однажды он приказал кандидату в члены команды «Йоа» сложить сушёную рыбу (собачий корм) в кормовой трюм. «Это невозможно, — услышал он в ответ. — Там нет места».

«А на корабле нет места для тебя, — сказал Амундсен, кусая губы. — Собирай вещи и проваливай».

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

Роланд Хантфорд. Покорение Южного полюса. Гонка лидеров. Манн, Иванов и Фербер, 2012

Критерии

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

Лояльность — вера в проект, менеджера и команду. Фундаментальный критерий. Если исполнитель не верит в проект, его польза может оказаться не просто нулевой, а отрицательной. Чем опытнее неверующий исполнитель, тем сильнее он может навредить. Людей с низкой лояльностью брать в команду опасно. Уровни:

−5 заклятый враг — 0 планктон — 5 соратник

Активность — умение взять инициативу и по-настоящему решить проблему. Может свернуть горы. Если исполнитель умеет «сделать», он может быть полезен даже, если базовый навык у него невысокий. Уровни:

1 тюфяк — 5 полководец

Упорство — способность дожать, действительно решить задачу. Признак профессионализма. Упорный исполнитель не сдаётся, добивается, доделывает и переделывает если нужно. Уровни:

1 ребёнок — 5 профессионал

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

1 слабак — 5 маг

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

Примеры исполнителей

В примерах ниже используется метафора осьминожек. Персонажи вымышленные, а список не претендует на полноту.

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

Бездарный балабол
Балабол будет «учить» вас и окружающих, как надо сделать. Сам при этом делать ничего не будет, потому что не умеет. Если вы провалитесь, скажет «я же говорил», если победите, постарается присоединиться к вашему успеху. Держитесь от балабола подальше.

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

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

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

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

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

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

Тест

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

Переставить ссылки в подвале сайта — хорошая маленькая задача для верстальщика. Сверстать пару рыбных блоков — плохая. Рыба не попадёт в реальный продукт, и проверка будет некачественной. В Дизайн-бюро Артёма Горбунова используют тест для проверки внешних технических команд.

В рассказе о текущей инициативе упоминается ведение задач в стандартной программе Календарь. Назовём методику управления задачами с помощью календаря «Календарём дел» и рассмотрим этот подход подробнее.

Суть

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

Технология

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

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

Если задача сделана, отметьте её знаком «+». Если задача отменена, и делать её не нужно, отметьте её знаком «-»:

Если время на исходе, а задача всё ещё не сделана, остановитесь и примите решение, как поступить. В вашем распоряжении три варианта: 1) забить, 2) попилить ещё, то есть добавить время, 3) пофлексить.

Забить

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

Если решили забить, поставьте в задаче крестик:

Попилить ещё

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

Если решили попилить ещё, поставьте крестик и запланируйте новую итерацию. Это поможет сохранить контроль:

Пофлексить

Пофлексить — значит придумать, как сделать задачу за отведённое время и без потери качества. Хитрость флекса в упрощении решения. Это самый хороший вариант — задача решается и решается в срок. Если придумали как пофлексить, доделайте и поставьте «+».

Пример календаря с большим количеством дел:

Результаты

Использование календаря дел имеет ряд полезных последствий.

План дня

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

Закрытый список

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

Оценка задач

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

Инкапсуляция ада

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

Хитрости

В календаре дел удобно группировать мелкие задачи. Типичный пример — разбор почты. Вместо того чтобы проверять почту в режиме онлайна, запланируйте несколько крупных задач и добивайтесь разбора инбокса до нуля. Этот же подход можно использовать для обработки задач в таск-менеджерах вроде Асаны, Джиры или Трело:

Пример группировки задачи из книги Тима Фериса «4-часовая рабочая неделя»

Если работаете над разными проектами, заведите для них разные цвета:

Если задача возникает постоянно, настройте повторяющуюся задачу. Обращение с повторяющимися задачами достойного отдельного рассмотрения.

Чтобы вводить крестики установите раскладку Бирмана.

Ошибки

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

Недостатки подхода

Календарь дел походит не всем. Если вы не любите планировать, заставить себя вести дела будет сложно:

Инструменты для ведения дел в календаре несовершенны. Неудобно делать задачи меньше получаса. Ставить плюсики, минусики и крестики — морока. Легко забыть отметить сделанную задачу, и она повиснет в неопределённом статусе. В примере календаря с большим количеством дел есть такая повисшая задача:

См. также

Текущая инициатива

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

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

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

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

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

3. Помогите сказать «нет». Если под вашим давлением разработчик возьмёт некачественную задачу, а потом не сможет её решить, пострадаете в первую очередь вы. Лучше узнать о проблеме на берегу, чем в открытом море. Помогите разработчику отказаться от негодной задачи:

• Чего не хватает в макете?
• Какие могут быть проблемы?
• Что я не учёл?

3. Убедитесь, что назначен дедлайн и забиты «гвозди». Задача без дедлайна не может быть решена по определению. Одного дедлайна недостаточно, нужны промежуточные чекпоинты — «гвозди».

Если разработчик не знает принцип «сделать», мягко подтолкните его вопросами:

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

Если разработчик понимает принцип «сделать», попросите назначить дедлайн и забить гвозди напрямую: «Пожалуйста, назови дедлайн и забей гвозди».

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

6. Не лезьте не в своё дело. Не сомневайтесь в профессионализме разработчика. Не лезьте в код. Если у разработчика не получится реализовать, задавайте наводящие вопросы, чтобы разработчик мог сохранить лицо:

• А как вы пробовали решить проблему?
• А почему вот это не сработает?
• А я вот слышал о таком способе…

7. Примите результат. Выделите себе отдельное время, чтобы проверить работу. Не рассчитывайте, что разработчик сделает это качественно. Он видит только часть системы и не может быть конечным контролёром.

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

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

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

1. Осознайте ответственность. Как только вы возьмёте задачу, между вами и дизайнером возникнут отношения исполнитель ↔ клиент. Вы — исполнитель. За взятую задачу будете отвечать вы и только вы, поэтому, если не сможете реализовать, если не успеете, если в дизайне чего-то не хватит — проблемы ваши. Хороший дизайнер поможет решить проблему, но целиком полагаться на помощь дизайнера безответственно.

Представьте, что задача — это пластилин. Как только вы берёте задачу, вы берёте «пластилин» в руки. Вернуть «пластилин» дизайнеру можно только двумя способами: 1) сделать и отдать слепленную фигурку — результат, 2) провалить задачу и отдать измятый пластилин — недоделанную работу и набор причин, почему вы провалились. Пока «пластилин» у вас в руках, за него отвечаете вы.

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

Чтобы понять задачу задавайте вопросы:

• В чём польза задачи?

• Кто этим будет пользоваться?

• Почему её важно сделать именно сейчас?

• Как эта задача связана с другими частями системы и с другими задачами? Что ещё придётся изменить в связи с этим в других местах?

• К какому сроку вы бы хотели получить решение?

• Почему это критично реализовать к указанному сроку?

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

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

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

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

5. Оставьте запас времени. Не планируйте впритык. Что-то обязательно пойдёт не так. Вы столкнётесь с неуловимым багом, дизайнер десять раз попросит подвинуть кнопочку, проект не соберётся, комп заглючит, свет отрубят. Заложите 20% запаса в срок, он вас спасёт.

6. Сделайте. Добейтесь результата в срок. Если не будете укладываться — придумайте, как упростить и предложите упрощение дизайнеру. Знать, что не успеваете и молчать — отстой. Упростить и не согласовать с дизайнером — отстой. Не успеть и молча продолжать делать — отстой. Ждать, что упрощение придумает дизайнер — отстой.

7. Сдайте. Утвердите работу у дизайнера. Он ваш клиент. Если он не сказал «ОК», вы не сделали, даже если вы всё запрограммировали и всё работает. Пока не сдали «пластилин» в ваших руках.

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

На выходе в день старта >> ваше понимание задачи (спецификация), дедлайн, набор контрольных точек — гвоздей.

В день дедлайна >> «ОК» от дизайнера и опубликованное в продукте решение.

P. S. Если всё-таки сорвали срок, признайте это как можно быстрее. Если дизайнер согласен работать с вами дальше, вернитесь к пункту 1. У вас должно возникнуть новое понимание задачи, новый дедлайн и новый набор контрольных точек.

P. P. S. И без детского сада, пожалуйста. Вам не нужен менеджер, чтобы следить за своими задачами.

Робине Тестар. Книга простых лекарственных средств. 15 век

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

Очевидный способ устранить хаос — найти каждому предмету своё место. Этот способ обладает недостатком: очень долго. Чтобы навести порядок мгновенно, срите в ячейки.

«Срать в ячейки» — универсальный приём организации хаоса. Любой бардак, разложенный по ячейкам, уменьшается на порядок. Метод и название подсмотрены автором в ЖЖ Артемия Лебедева:

nolar: Как сделать бардак самоприбираемым?
tema: Срите в ячейки.

В жизни

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

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

С десятками баночек и пакетиков детского питания будет проще иметь дело, если разложить их в коробки:

Внутри «ячеек» хаос сохраняется, им можно заняться позже:

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

См. также

Бесконечные банковские ячейки

Рабо­чие обе­щали покле­ить обои к пят­нице. Пят­ница при­шла, а покле­ено только пол­стены. Ока­зы­ва­ется они поте­ряли ключи и два дня не могли попасть в квар­тиру. Ёлки‑палки.

Дизай­нер взялся сде­лать макет за неделю. В поне­дель­ник макет не готов. Вдох­но­ве­ние при­шло к дизай­неру только на выход­ных, нужна ещё неделя. Уф.

Команда раз­ра­бот­чи­ков под­твер­дила, что доба­вить бей­джик на икону мобиль­ного при­ло­же­ния — пара дней, они сами ско­опе­ри­ру­ются с сер­вер­ным про­грам­ми­стом и всё сде­лают. Через неделю бей­джика нет. Серверный про­грам­мист сде­лал свою часть, черк­нул об этом в системе управ­ле­ния зада­чами, мобиль­ные раз­ра­бот­чики не заме­тили. Три дня над зада­чей никто не рабо­тал, нужно ещё три дня, чтобы доде­лать и опуб­ли­ко­вать. Блин.

У опи­сан­ных ситу­а­ций одна природа:

менеджер — лох, не прибили гусеничку.

Задача похожа на гусе­ницу, кото­рая изви­ва­ется всем телом как чер­вяк на ско­во­родке. Вероятность, что гусеница сама приползёт в наме­чен­ную точку в заданное время стре­миться к нулю. Чтобы сделать вовремя, гусе­ницу нужно при­бить «гвоз­дями», тогда она не сдвинется:

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

Свой­ства гвоздей

Конкретность

Гвоздь должен быть чёткой договорённостью. «Три макета к четвергу к 15:00» — хороший гвоздь. «Давай, чтобы на этой неделе всё было сделано» — плохой.

Несдвигаемость

Забитые гвозди нельзя сд­вигать. Даже если испол­ни­тель гово­рит, что у него ничего не готово, нужно встре­титься в намеченное время и обсу­дить теку­щее поло­же­ние дел. Это одновременно продвигает проект вперёд — на встрече можно что-то решить или даже сделать — и дисциплинирует исполнителя: показывает ему, что халявы не будет. Гвоздь — на то и забит, чтобы не двигаться.

Многоуровневость

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

Ритмичность

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

В жизни

Советский союз применял пятилетнее планирование в национальном масштабе с 1928 года:

Гугль применяет метод ЦКР (цель и ключевые результаты), планируя работу кварталами. Метод был внедрён Джоном Дором через год после основания Гугля и используется до сих пор:

Слайд из оригинальной презентации Джона Дора

В Дизайн-бюро Артёма Горбунова. Про­екты планируют понедельно, в конце каждой неделе демонстрация результатов клиенту:

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

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

См. также заметку о стоимости задач

Ошибки

В идеальном мире гвозди нужны исполнителю — тому, кто делает работу, а не клиенту — тому, кто принимает результаты. Хороший исполнитель сам прибивает гвозди, чтобы сделать первоклассную работу: «Николай, я предлагаю посмотреть промежуточные результаты 8-го, 14-го и 28-го мая. Когда тебе удобно?»

Если испол­ни­тель организован слабо, что явля­ется состо­я­нием по умол­ча­нию для боль­шин­ства, кли­енту приходится забивать гвозди самостоятельно:

— Алексей, давай договоримся о просмотре промежуточных результатов, предложи, когда.
— Ну, не знаю...
— Давай смотреть всё по четвергам в 18:00?
— Ну, хорошо...

Кли­енту про­тивно прибивать гвозди, но лучше уж так, чем провалить задачу или проект. Так или иначе, гвозди должны быть забиты.

Одних гвоздей недостаточно для успешного проекта. Но без них провал практически гарантирован. Гвозди в гусенице — необходимое условие успеш­ного проекта.

См. также

Совет о гвоздях в гусенице

Текущая инициатива — это способ концентрации внимания, описанный Марком Форстером в книге «Сделайте это завтра».

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

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

Делать

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

Первым делом

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

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

Каждый день

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

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

Заканчивается, когда сделано

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

Когда использовать

Гигантские задачи

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

Разбор дел из долгого ящика.

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

Дефектные системы

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

Нет, спасибо, мы слишком заняты

Запуск

Текущую инициативу не надо путать с проектом. Проект делают в основное рабочее время. Но для запуска проекту может понадобиться особенно пристальное внимание. Тогда его можно сделать текущей инициативой.

На практике

Ежедневную работу автор ведёт в стандартной программе Календарь, которая поставляется с операционной системой МакОС. Метод описан в совете.

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

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

Плюсики означают, что в этот раз автор действительно занимался задачей

См. также

Книга «Сделайте это завтра» на Амазоне

P. S. Из твитера Эдварда Тафти:

Твит

P. P. S. Эту заметку автор написал текущей инициативой.

Утренняя планёрка в ресторане Кастел

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

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

Ключевые свойства нормального потока:

Синхронизация

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

Стив Джобс рассказывается о еженедельных встречах руководства Эпл:

Шаблоны и инструкции

Шаблоны, инструкции, алгоритмы — смазка нормального потока задач.

В Дизайн-бюро Артёма Горбунова существует процедура продажи проекта, шаблоны писем, типовой план проекта:

В «Додо Пицце» все станции снабжены инструкциями:

Управляющий партнёр сети «Пятёрочка» Дмитрий Потапенко рекомендует блок-схемы алгоритмов из школьного учебника:

Обработка нестандартных задач

Нормальный поток задач плохо справляется с нетипичными задачами. Поэтому инструкции должны предусматривать удаление нестандартных задач из нормального потока:

Отношение Стива Джобса к качеству продуктов завораживает. Из книги Уолтера Айзексона:

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

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

Когда Джобс решил построить во Фримонте наисовременнейший завод по производству Макинтошей, его эстетические амбиции и страсть к контролю достигли апогея. Ему хотелось, чтобы машинное оборудование было выкрашено в яркие цвета, как логотип Эпл, но он так долго разглядывал образцы краски, что директор по производству Мэтт Картер в итоге установил обычное оборудование, бежевых и серых цветов. Осмотрев завод, Джобс распорядился, чтобы станки перекрасили в яркие цвета, которые он выбрал. Картер отказался. Оборудование было очень ценное, и покраска могла иметь нежелательные последствия. Он оказался прав. Один из самых дорогих станков, который всё-таки перекрасили в ярко-голубой, стал плохо работать, и его окрестили «Каприз Стива». В конце концов Картер ушёл. «Борьба с ним требовала слишком много сил, а поводы для стычек яйца выеденного не стоили, так что мне надоело», — рассказывал он.

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

Джобс был раздавлен.

— Кажется, мне все ясно, — сказал он и выбежал вон из комнаты. Никто за ним не последовал.

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

Раз уж мы начали с рассказа о Стиве Джобсе, пусть он, но уже умудрённый опытом и вернувшийся в Эпл, подведёт итог:

Продукты — пакеты внимания. Чтобы сделать отличный продукт приходится жертвовать неважным. Это ок.

P. S. Не путайте упрощение с халтурой. Совет о перфекционизме.

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

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

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

Уведомляют в трёх точках:

1. Собираюсь что-то сделать — чтобы предупредить ошибку.
2. Что-то сделал — чтобы другие участники знали, чего ждать.
3. Получил результаты — чтобы распространить знания о продукте и гипотезах.

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

См. также

Тим Ферис Позволение плохому случаться (на английском)

P. S.

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