Заметки менеджера: проблема последней мили

У связистов есть понятие — «последняя миля». Это когда магистральные каналы уже проложены и надо дотянуть связь до конкретного пользователя.

В закладки
Аудио

В ИТ вообще и у руководителей проектов в частности тоже можно ввести понятие «последней мили». Это когда было сделано 90% работы и каждый из участников проекта сделал «да всё, ну почти всё, там остались мелочи», но это никак не складывается в конечный, завершённый и красивый результат.

У нас в True Engineering есть следующие мысли по этому поводу. Разберём на примере.

Стандартная ситуация из трёх актов:

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

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

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

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

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

Описанные выше упражнения и воспитания менеджеров и их подчиненных должны привести к простому принципу:

Делай своё дело настолько хорошо, чтобы не пришлось к нему возвращаться.

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

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

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

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

В менеджерском цикле True Engineering уже вышли такие статьи:

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

Написать
{ "author_name": "Дмитрий Талочкин", "author_type": "self", "tags": ["\u043c\u0435\u043d\u0435\u0434\u0436\u043c\u0435\u043d\u0442"], "comments": 7, "likes": 26, "favorites": 73, "is_advertisement": false, "subsite_label": "hr", "id": 84224, "is_wide": false, "is_ugc": true, "date": "Mon, 23 Sep 2019 13:13:04 +0300", "is_special": false }
Создать объявление на vc.ru
Вебинар «Словения: потенциал инвестирования в недвижимость»
10 апреля Онлайн Бесплатно
(function(d, ver) { var s = d.createElement('script'); s.src = 'https://specials-f378ef5.gcdn.co/Covid19Quiz/all.min.js?' + ver; s.async = true; var container = d.getElementById('covid-quiz'); if (container) { s.onload = function() { new Covid19Quiz.Special({ css: 'https://specials-f378ef5.gcdn.co/Covid19Quiz/all.min.css?' + ver, container: container, location: 'article', share: { url: '', title: '', } }); }; } d.body.appendChild(s); })(document, '5fa16901');
0
7 комментариев
Популярные
По порядку
Написать комментарий...
5

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

Ответить
2

И понятно, почему минусуют. Очень часто видны ситуации, когда заказчик не может чётко сформулировать каков желаемый результат, но хочет зафиксировать цену - и чем меньше, тем лучше. Вполне понятно и желание людей получить деньги за выполненную ими работу. Тем более что и дураки бывают не только среди исполнителей, но и среди заказчиков... Потому всякие Agile'ы и напридумывали. Они не то чтобы решают этот вопрос до конца - но хотя бы ограничивают взаимный беспредел рамками одной (небольшой) итерации...

Ответить
0

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

Когда размытое ТЗ - тут никаких вопросов нет.

Ответить
1

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

Мне самому как то поставили "совершенно чёткую" задачу - внедрить BI (SAP BW) - положили на стол пачку денег (фигурально - реально это был безнал - на столе бы это не уместилось) и сказали "внедряй". Когда я попытался уточнить постановку задачи, меня прямо спросили - ты у нас в теме или как?

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

Ответить
0

Текст очень похож, как на сайте Горбунова почти https://bureau.ru/soviet/20181231/ 

Ответить
0

Доводить работу до идеала к сожалению значит не сделать больше работы. А значит бизнес страдает, так как КПД 30-70% (к кого как) приносит 90% прибыли.

Ответить
0

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

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

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

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

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

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

Ответить

Прямой эфир