Этой статьёй я открываю новый цикл «Проект для Исполнителя». Цикл этот я готовил давно, записывал наброски. Но когда захотел выбрать пять правил для первой статьи, то неожиданно увидел, что их у Исполнителя много, и все они важные и правильные. Пришлось некоторые объединить, менее важные — оставить на потом. Остались универсальные, годные не только для команды Исполнителя, но и для всего проекта.
Конечно же, всё в нашем мире относительно: серьёзное нарушение второстепенного правила с отважным применением разных навыков даст граблям куда больше работы, чем незначительное нарушение самого важного правила. Поэтому спорьте в комментариях и предлагайте свои варианты.
А я сажаю рядом Оппонента и даю ему возможность пару раз оспорить каждое правило.
Правило 1. Люди решают всё, или Своих не бросаем
Старый постулат, испытанный миллионами боёв и веками истории. Человек со своим опытом, проблемами, настроением и обстоятельствами по крупицам строит результат проекта. А проект — это всегда стресс, неопределённость и путь в неведомое. Ожидания сбудутся в зависимости от того, как решатся его проблемы, и от комфорта работы будет зависеть продуктивность людей.
Второе ключевое слово в заголовке — «своих». Кто такие «свои»? Конечно же, команда. Сплочённая, когда один за всех и все за одного. Состоящая из мастеров своего дела. Так?
Так, но не до конца.
Однако именно так я считал, когда начинал руководить своим первым проектом. Но однажды я узнал, что команда — не только Исполнителя. Правильно так: небольшая команда Исполнителя становится частью команды Заказчика. И вот уже новым «своим» мы помогали с отчётностью до двух ночи. А потом были самыми желанными гостями на корпоративе Заказчика, и все его новые проекты были наши.
Конечно, в разумно составленной команде есть специалисты всех уровней: от начинающих до экспертов. Почему — очевидно: работы тоже бывают разные. Профи, выполняющий работу джуна — это недоработки руководителя проекта.
Важен не класс, а мотивация. Да, главная задача РП — достичь цели проекта. Путей к ней много, но все они так или иначе идут через правило №1.
Оппонент: А как же пирамиды построили? Рабов в команды зазывали? Да и сам посмотри вокруг: правило №1 — это жёсткая дисциплина и чёткое, неукоснительное соблюдение сказанного шефом, а не эти ваши «не бросаем».
Отвечаю: Не историк я. Но история показала, что рабский труд низкопроизводителен. Жизнь не стоила ничего, да и надсмотрщиков за рабами тоже содержать надо. С человеком работали и тогда: нашли же знающего секрет кладки, простоявшей тысячелетия. Методы другие были, в наших условиях они неприменимы. Жёсткое армейское руководство — возможный вариант, но ненадолго: участники разбегутся, а обучение новых — недешёвое удовольствие. И надо ещё с Заказчиком работать, а там не выйдет так, как с рабами.
Оппонент: Всё равно, «не бросаем» — это только слова. Сам же знаешь, большинству в команде интересна не команда, а карьера. Ну, или деньги. Вот это — ценности. И за них люди на всё готовы. Проект завалить? Легко, если на новом уже я буду руководить.
Отвечаю: Люди разные бывают. И надо управлять ожиданиями каждого в большой команде Исполнителя и Заказчика. У меня было в списке такое правило, очень важное, но оно влилось в правило №1. Если ожиданиями грамотно управлять, то большинство перечисленных тобой конфликтов урегулируются. А там, где не выйдет — надо мониторить ещё на входе, это вопрос кадровый, к сожалению.
Правило 2. Ставь себя на место партнёра
Кто такой партнёр? Тот, с кем ты взаимодействуешь. Для чего это правило? Для понимания партнёра! И это понимание приносит важные и интересные результаты.
Знакома вам фраза: «Мы выполним все пожелания Заказчика»? Да кто ж её не слышал! И вот у Заказчика рождаются феерические фантазии, а мы… Правильно, делаем. Поскольку согласовано, пересогласование долгое, и никто его не одобрит.
А теперь я поставлю себя на место Заказчика и тоже фантазирую. Приехал я из командировки в джунгли, где всю цивилизацию забыл. И вот на улице увидел автомобиль, а у него сзади запаска висит — бывают такие. Посчитал колёса — четыре, сзади пятое. Командировочные мне выплатили, на машину хватает, и много остаётся. Прихожу я в магазин, говорю: машину хочу. Помогли мне выбрать, говорят — вон там, в ангаре, предпродажная подготовка, там все ваши желания по машине в жизнь претворят.
Прихожу я в ангар, смотрю на машину — нет колеса сзади. У меня и мысли нет, что у этой модели оно в багажнике. «Пятое колесо хочу», — говорю. И бросаются они мне пятое колесо приделывать.
Что бы я, как Заказчик, хотел? Чтобы мне косяк в виде пятого колеса прикрутили? Да нет, конечно. Если б понял ситуацию, то попросил бы, чтобы объяснили, как правильно делается. А кто виноват, что я не понял? Исполнитель!
Одна из обязанностей профессионального Исполнителя — объяснять Заказчику ситуацию.
Или другой пример. Сроки горят, надо сдавать задачу. Почти всё готово, кроме одного сложного алгоритма. Есть возможность сделать простую затычку, в 99 % она работает, но в 1 % — теряет данные. Запускаем в релиз? Конечно, сроки горят. Что бы вы выбрали на месте Заказчика: ездить на исправной машине послезавтра или на сломанной сегодня? Правильно: зависит от обстоятельств. А их знаю только я — Заказчик. И угадайте, хочу ли я, чтобы кто-то угадывал, что я хочу? 😊
Почему это правило второе? Потому что кардинально меняет всю ситуацию в проекте и экономит средства. Отсутствие взаимопонимания — один из самых существенных пожирателей времени в любом проекте. А для достижения всеобщего понимания и счастья требуется третье правило.
Оппонент: А я сразу приведу другой пример: твой любимый Заказчик бил баклуши полгода. Тебе пора акт подписывать, деньги принимать да зарплату платить, а у него именно вот сейчас отчётность и реально некому работы принимать. Что, входим в положение собеседника и без оплаты сидим?
Отвечаю: Сроками, вообще-то, тоже управлять надо. Или отчётность приходит неожиданно, как зима для коммунальщика? РП должен понимать, когда и с чем Заказчику сложно будет. Но предположим, что-то непредвиденное свалилось, или прозевал сам, — не укладывается Заказчик в сроки. Тут чрезвычайная ситуация, и решать её нужно в особом порядке в зависимости от обстоятельств. Так же, как если у меня вдруг ключевой сотрудник заболел и замены не найти. В большинстве случаев при соблюдении правила №1 стороны идут навстречу друг другу. Но и здесь важно ставить себя на сторону Заказчика и представлять, что сделал бы на его месте.
Оппонент: И тут приходит кладовщик и жалуется: «Знать никогда не знали никаких бухгалтеров с их счетами, а в ЕРП теперь статьи надо проставлять за бухгалтера. У нас работы прибавится, у них убавится. И вот зачем нам эта ЕРП?» И как будем входить в положение? Перепишем чего-нибудь?
Отвечаю: Нет, конечно. Об этом будет в четвёртом правиле. А здесь решение стандартное: по завершении проекта обязанности всегда перераспределяются, и об этом надо проинформировать Заказчика. Если меры к нужному времени не приняты — напомнить. Применим здесь правило №2. Что бы ты сделал на месте кладовщика?
Оппонент: К своему руководителю бы пошёл.
Отвечаю: Вот и посоветуем ему это. А так как сам завскладом этот вопрос решить не может, тут имеем ржавую эскалацию, и надо помочь её расшевелить и решить вопрос: например, переводом одного бухгалтера в помощь складу. Но здесь внутренний вопрос Заказчика, и помочь мы можем лишь советами да напоминаниями, только уже, по возможности, по финальному адресу.
Правило 3. Будь открыт и настрой коммуникации
Самое сложное правило для интроверта. Сколько раз у меня бывало, когда требования Заказчика кривые, а я тихонько делал как надо и потом ставил перед фактом и объяснял, почему так. И прокатывало, пока не пропустил один раз важную особенность в работе Заказчика. А надо было коммуницировать.
Если мои предположения правильные, и я правильно объясняю, то Заказчик поймёт (с учётом того, кому надо объяснять, это вопрос отдельный). Принимающий решение должен обладать всей необходимой информацией. И часто правильнее предоставить больше информации Заказчику, чем пытаться вытрясти из него информацию.
Важно: Плохие коммуникации → Недостаток информации → Неверные решения → Лишние трудозатраты.
Правило работает для всей большой команды.
Представьте, что проект — это полёт на самолете. Молчание пилота в течение всего полета — это не признак уверенности, а повод для паники. Точно так же и в проекте: тишина пугает больше, чем плохие новости.
И для меня как специалиста тоже знать, зачем нужна та функция, которую я дорабатываю. Об этом точно будет отдельная статья.
Плохие коммуникации — причина лишних трудозатрат во всех проектах, в которых я участвовал (в разной мере, конечно). Общие стандарты не всегда помогают, поэтому исправляемся, работаем. Тут каждому участнику есть, над чем поработать.
Почему оно третье? Ведь это очень важное правило, наравне со вторым. Третьим я его сделал только по принципу интроверта: «сначала пойми — потом беседуй». Прозрачность порождает доверие, а доверие — это валюта, на которую покупается лояльность и дополнительное время при проблемах.
Оппонент: Ага, будем следовать этому правилу. Создадим общий чатик во весь проект, всех Заказчиков добавим, и пусть пишут туда, кто что захочет. Вот потеха-то будет! Зато все в курсе всего. А я достаю секундомер и засекаю срок жизни этого чатика.
Отвечаю: А ты прочти правило ещё раз. Видишь там слово «настрой»? Доступность информации не означает её беспорядочное распространение. Как минимум, есть правила безопасности. Но сейчас важнее, что каждый должен получать только нужную ему информацию, иначе все будут только разбирать спам. Как правильно построить потоки информации, и какие создавать чатики — это вопрос настройки коммуникаций. Так что, коллега, ваш секундомер засекает не срок жизни правила №3, а срок жизни его уродливой пародии.
Оппонент: Мы тут чуть прод не снесли. Написал один товарищ письмо, и в буковке ошибся. За секунду до смерти прода я заметил и не запустил процесс. Ну что, бежим информировать Заказчика о наших процессных дырках?
Отвечаю: Худшие новости — это те, о которых узнают внезапно. Не бежим, а продуманно идём. И тут есть несколько вариантов, сейчас один рассмотрим. Ошибку надо сразу же проанализировать и принять меры против повторения. А потом известить Заказчика: был инцидент, меры приняты, какие будут замечания? Допускаю, что серьёзность последствий можно сбавить, поскольку не произошло ничего, но это уже от контекста зависит. Хитрый ИИ мне порекомендовал отрапортовать: «в ходе учений по безопасности обнаружилось…», но я против лжи, да и применив правило №2, понял, что Заказчик вряд ли будет доволен несанкционированными учениями в районе прода.
Правило 4. Делай как для себя!
Моё самое любимое и, увы, самое часто нарушаемое правило в индустрии. Это не про «работать бесплатно». Это про внутренний стандарт качества. Представьте, что вы не сдаёте модуль Заказчику, а передаёте своему лучшему другу, который будет этим пользоваться каждый день. Стали бы вы для него оставлять «баги, которые потом пофиксим» или неудобный интерфейс?
Правило тоже ёмкое и много включает в себя. В приведённом выше примере предостереги Заказчика от ошибки, которой не хотел бы видеть в своей программе. Проконтролируй джуна, который не ведает, что творит, ведь разве ты хотел бы сделать для себя так же? Переборов лень, переделай за собой что-то. Поговори с Заказчиком: «Могу сделать быстро и за час, но будут такие вот ляпы, которые когда-то потом обойдутся в час семерым пользователям и в два дня исправлений. А могу сделать за день, но тогда мы сдвинем сроки и суммы, или взамен вот эту кнопочку не сделаем, она не обязательна вроде. Или исправлю в следующем этапе, но это не 7 часов плюс, а 9, поскольку надо все точки заново открывать, вспоминать». Пусть он выберет как удобнее…
Оппонент: Ну вот сдержаться не могу! Он выберет «сделай всё правильно за час!». Ну ладно, за три…
Отвечаю: С Заказчиком надо работать. Ситуация банальная, надо предусмотреть её. Заказчик должен понимать, что скидки не безграничны, не бывает работ «за так». И если бюджет ограничен, то надо ограничивать и доработки. В любом случае, по каждой такой ситуации не должно возникать вопросов. У задач должен быть приоритет, чтобы было ясно, чем жертвуем, если что…
Оппонент: Ты мне про универсальность говорил. Вот ты сидишь, работаешь — и вдруг озарение приходит, что сможешь сделать это классно и универсально, но за три дня вместо четырёх часов. Попробуй-ка объясни целесообразность Заказчику!
Отвечаю: В этом случае надо понимать, что выгодоприобретатель — не Заказчик. Точнее, Заказчик тоже, но в меньшей степени. У Исполнителя эти затраты могут окупиться в этом же проекте, если решение применить ещё раз 5-6, а в других проектах — обязательно окупится. Я бы разделил здесь затраты, но как именно — зависит от контекста.
Почему это правило — четвёртое? Потому что оно превращает ремесленника в мастера. Это вопрос профессиональной гордости. Правило снижает повторные трудозатраты, повышает оценку и опыт каждого участника, приносит новых клиентов при должном обращении. И маркетологи смогут показать результаты на встречах.
Правило 5. Вырабатывай правила и следуй им
Где нет законов, там царит анархия. Проект — это минигосударство, правила игры в котором должны быть понятны всем: как ставить задачи, как принимать результаты, как проводить совещания, как эскалировать проблемы.
Должны быть и личные правила, не противоречащие общим. Мне они помогают экономить время: не думать, что делать, а довериться опыту и правилу. Именно отражение опыта превращает правила в мощный проектный инструмент. Поэтому написано «вырабатывай», а не «придумывай».
Важно и следовать правилам. Правило, которое кем-то игнорируется, вносит беспорядок, по аналогии будут нарушаться и другие правила. Возникнет ситуация хаоса, как во всеобщем чатике, придуманном Оппонентом.
Почему оно тоже в топ-5? Потому что оно важное, универсальное, защищающее от граблей и неожиданно — тоже часто нарушаемое.
Оппонент: Работал я в проекте с правилами. Каждый шаг был расписан. Угадай, сколько времени этот шаг занимал? Все правила в голове держать невозможно, их слишком много. И вот перед каждым шагом я обыскиваю регламенты в поисках нужного правила. Один раз поступил как требовалось, но в другом регламенте, как оказалось, другие требования. А когда меня начали дёргать — я уже и не помню, почему против регламента пошёл. Хорошо, что вовремя вспомнил и показал тимлиду, а то уж чуть не уволить хотели. Но на оправдание почти день ушёл! И столько же уходит на ошибки в ТЗ. Написали ставку налога на доходы 45% вместо 15, опечатка. Так бы я сам исправил — но у нас же правила!
Отвечаю: Заметь, тут не само правило помешало. Мешал порядок применения. Свод правил должен храниться в удобном для поиска и использования виде. И дубли нужно отслеживать. А для мелких ошибок рекомендую применять упрощённый порядок исправления, тут никто не будет против, скорее всего. Ещё совет: ссылки на правила, которые я часто применяю, или могу забыть их расположение, сохраняю в списочек. Веришь или нет — он получается небольшой.
Оппонент: Ты тут развернул свои правила, а ничего нового не сказал. Это тот же Agile, но неудачно обрезанный и дополненный. Ну нет в Agile ничего про правила. Зато есть главное — работающий продукт. И готовность к изменениям есть, а где она у тебя? Заменена правилами?
Отвечаю: А я и не скрываю, что ценю Agile. Но это тоже инструмент, и вот так я им воспользовался. Работающий продукт — цель проекта, а недостижение цели противоречит правилу 4, например. Изменения важны, но в проектах частенько к ним не готовы. Вспомни, с чем обычно связаны изменения? С объёмом задач, а не с правилами. Что касается объёма — это тоже к правилам 2 и 4. А вот когда правила всё же меняются — это к вопросу о «вырабатывай», — то не всегда с первого раза, но корректировать можно. В разумных пределах, конечно.
Достаточно ли применения пяти постулатов для успешного завершения проекта? Нет, конечно. Проект выполняют люди, а не правила. Постулаты — это не магические заклинания, а профессиональный инструмент в руках мастеров. Они не гарантируют успеха, но создают пространство, в котором вероятность успеха крайне высока. В этом пространстве каждый участник команды уважаем как человек, работа его комфортна, а разрозненные исполнители превращается в единый организм. Там «чуть не снесли прод» укрепляет команду и результат, а «хочу, чтобы кнопка стала зелёной» становится началом диалога о лучшем решении.
Мои постулаты — не панацея, не догма, а инструмент, выработанный опытом — моим и коллег, в котором были и прорывы, и ошибки, и стресс перед сдачей, и общее ликование в час победы. Правила живые, это их первая редакция, и возможно, через год я сумею разместить в них и работающий продукт, и готовность к изменениям, и «не сдавайся», и «всегда думай». В руках хорошей команды верные правила оживают, превращаясь в культуру вашей работы и принося новый опыт и новые успехи. Ведь даже самая совершенная система — лишь отражение уровня зрелости команды, которая её создала.
