У связистов есть понятие — «последняя миля». Это когда магистральные каналы уже проложены и надо дотянуть связь до конкретного пользователя.
В ИТ вообще и у руководителей проектов в частности тоже можно ввести понятие «последней мили». Это когда было сделано 90% работы и каждый из участников проекта сделал «да всё, ну почти всё, там остались мелочи», но это никак не складывается в конечный, завершённый и красивый результат.
У нас в True Engineering есть следующие мысли по этому поводу. Разберём на примере.
Стандартная ситуация из трёх актов:
- Акт первый. Клиент присылает письмо со списком вопросов, каждый из которых адресован профильным специалистам. Что делает менеджер? Пересылает команде письмо с пометкой, мол, ребята дайте ответы на поставленные вопросы. Некоторые сразу указывают это в тексте в стиле «Вася — первый, второй, пятый вопросы, Петя — третий, четвёртый, Коля — шестой, седьмой».
- Акт второй. Менеджер получает от подчинённых ответы в стиле «они сами виноваты, мы им сказали, они вот так ответили, времени пока не было, но там и так всё понятно, и вот код, где всё видно». Скажем честно: никто из них не ответил на вопросы клиента. Клиенту ничего не понятно из кода. Клиенту нужны даты и в идеале письма, в которых чётко видно, когда, кто, кому, что написал или сказал и когда он получит желаемое и как это бьётся с планами.
- Акт третий. Итак, менеджер садится и начинает тянуть эту последнюю милю — задаёт уточняющие вопросы, добавляет контекст, переписывает ответы в рамках деловой этики и потом всё это ещё раз показывает спецам, чтобы убедиться, что ничего не упустил.
Такой подход приводит к тому, что все ещё больше расслабляются и считают, что «менеджер болтать умеет и всё равно завернет красиво». Так что можно даже не писать ничего, а выловить менеджера в коридоре и быстренько на жаргоне дать вводную.
Аналогично происходит с внедрением решений («код же весь написан, UI немного подпилить, да и сопровождающие документы не особо нужны: и так и всё понятно»), созданием маркетинговых материалов («ну вы там напишите чё-нить, а дизайнеры сделают красиво, а над структурой документа пущай боссы думают») и многим другим.
В результате мы имеем команду условных профессионалов, каждый из которых сделал что-то и считает, что сделал хорошо, но никто из них не задумывается над этой самой «последней милей». Как собрать этот результат воедино, чтобы всё доехало до клиента в работающем и шикарном виде. Как тот же iPhone, который приятно даже из коробки доставать и на каждому шагу мелочи продуманы.
В качестве упражнения можно брать одного специалиста проектной команды и проходить с ним эту последнюю милю. Чтобы именно он тянул это всё до шикарности: задавал вопросы, переписывал текст, продумывал структуру и стиль ответов.
Описанные выше упражнения и воспитания менеджеров и их подчиненных должны привести к простому принципу:
Делай своё дело настолько хорошо, чтобы не пришлось к нему возвращаться.
Необходимо каждого из более-менее вменяемых сотрудников команды заставлять проходить такую «последнюю милю». Пусть не в сторону клиента, а в сторону менеджера, но как часть хорошего структурированного ответа в сторону клиента.
И если сотрудник хотя бы раз напишет нормальный ответ — а для этого требуется несколько раз уточнить и столько же раз переписать свою заготовку, — то в будущем он будет думать, как отвечать в следующий раз на вопросы менеджера.
Периодическое повторение таких заданий с заядлыми уклонистами от готового результата даст им понять, сколько непродуктивного времени менеджера уходит на шлифовку информации. Скажем честно: намного эффективнее вырастить специалиста до профессионала, который понимает, кому, что и зачем он отвечает, чем каждый раз тянуть «последнюю милю» в одиночку.
P. S. Если вам понравился этот текст, не исключено, что другие тоже будут полезны.
В менеджерском цикле True Engineering уже вышли такие статьи:
Как тут не вспомнить недавнюю тему про создание сайтов и как меня минусили за то, что я был против по-часовой оплаты программистам. Минусующие упорно делали вид, что описанной Вами проблемы не существует, а заказчик - сам дурак.
И понятно, почему минусуют. Очень часто видны ситуации, когда заказчик не может чётко сформулировать каков желаемый результат, но хочет зафиксировать цену - и чем меньше, тем лучше. Вполне понятно и желание людей получить деньги за выполненную ими работу. Тем более что и дураки бывают не только среди исполнителей, но и среди заказчиков... Потому всякие Agile'ы и напридумывали. Они не то чтобы решают этот вопрос до конца - но хотя бы ограничивают взаимный беспредел рамками одной (небольшой) итерации...
Это все верно, конечно. Но там речь шла о ситуациях, когда Заказчиком присылается список конкретных вещей, недоработок и тут начинаются качели.
Когда размытое ТЗ - тут никаких вопросов нет.
Виктор, я вас понял. Тот текст я не видел, мне сложно о нём утверждать что-то прямо. Но в жизни видел очень разные ситуации - как и представления о том, что такое "четкое ТЗ" у разных людей.
Мне самому как то поставили "совершенно чёткую" задачу - внедрить BI (SAP BW) - положили на стол пачку денег (фигурально - реально это был безнал - на столе бы это не уместилось) и сказали "внедряй". Когда я попытался уточнить постановку задачи, меня прямо спросили - ты у нас в теме или как?
В теории должна была бы быть корпоративная стратегия, цели бизнеса и вытекающие из них цели, ожидаемые результаты и показатели внедрения, а также приоритеты. А на практике все было по понятиям. И ведь что интересно - внедрил и результаты всех действительно устроили...
На мой взгляд проблема реальная, а подход весьма спорный, поскольку содержит в себе принципиально ошибочные предположения. А именно - что если каждый по отдельности выполнит свою работу "хорошо" (или даже "идеально") то это приведёт к хорошему итоговому результату. На практике это далеко не так.
Во-первых потому, что часто изначальный результат к моменту появления может уже не устраивать заказчика (а возможно он с самого начала не устраивал - просто не видя его заказчик этого не понимал).
А во-вторых, поскольку ошибка может быть в системе и её структуре - тогда сколько идеально сделанные рукава от разных костюмов не сшивай - результат будет далёк от желаемого, тем более - идеального.
И наоборот - полно примеров того, когда далеко не идеальный со множества точек зрения результат прекрасно устраивает заказчика (не смотря на ошибки, огрехи и прочие недостатки - на которые заказчик закроет глаза, если главное его устраивает).
За конечный результат отвечает руководитель проекта (или продукта). В этом и заключается его роль. У автора же он показан как секретарь, пересылающий письма специалистам, которые и должны и думать и делать всю работу за него.
А ведь они могут и вовсе не видеть картины целиком и тем более не представлять взаимных договорённостей и ньюансов отношений с заказчиком. Да и не должны в общем-то. Это работа руководителя проекта....
Текст очень похож, как на сайте Горбунова почти https://bureau.ru/soviet/20181231/
Доводить работу до идеала к сожалению значит не сделать больше работы. А значит бизнес страдает, так как КПД 30-70% (к кого как) приносит 90% прибыли.