Многие руководители жалуются на «испорченный телефон» при передаче важной инфы подчинённым. Даже когда они собирают большое совещание на кучу народа, выступают на этом совещании лично, рассказывают подробно, приводят доводы, почему-то изрядная часть сотрудников их не слышит.
Часто ошибка заключается в том, что вы высоко сидите, далеко глядите, а подчинённые погрязли в операционке и им просто не до ваших стратегических распоряжений, предостережений, увещеваний, справиться бы с текущими вопросами. В такой ситуации лучше вообще отказаться от такого информирования и помочь разгрести операционку.
Если же эта проблема неактуальна, то применяем следующие решения:
Привлеките внимание
Объясните коллегам, почему ваше сообщение важно. Можно использовать какую-нибудь яркую метафору. В мою бытность продактом «Системных технологий», гендиректор однажды на собрании провёл параллель с детьми Могадишо. Ну, что типа на словах всех волнует судьба детей в Могадишо, но, положа руку на сердце, нам на них плевать. И было бы неплохо, чтобы мы перестали относиться к нашим продуктам как к детям в Могадишо. Из памяти стёрлось, о чём была остальная часть собрания, но параллель запомнилась. Ну и пункт был выполнен, внимание было привлечено. Можно рассказать о конкретных угрозах, какой-то опасной ситуации, которая может произойти и которая напрямую повлияет на людей в зале.
Дайте решение
Да, бывают совещания, которые как раз посвящены выработке решения, всякие мозговые штурмы, мозговые атаки и проч. Но мы говорим о немного другой ситуации, когда всё более-менее определённо и вы знаете, что делать. Поясните в общих чертах основные пункты плана, по которому будем действовать, чтобы угроза, озвученная в предыдущем пункте, не стала реальностью.
Распределите роли
Объясните, какой именно руководитель какого именно отдела какую часть плана будет выполнять. Если необходимо, детализируйте до уровня ключевых исполнителей. Без этого хода, не вполне ясно, кто и что должен делать, люди могут понадеяться друг на друга и ваш план провалится.
Вам совершенно точно придётся несколько раз повторить сказанное в предыдущих пунктах. Обязательно нужно разослать по итогам информирования письмо, в котором информация будет продублирована. Не исключено, что распределение ролей придётся повторить устно. Это нормально, мало кто с ходу воспринимает и запоминает новую информацию, особенно в условиях информационного шума. Это никому не нравится, но если вы действительно хотите донести важную информацию, придётся это делать.
Ответьте на вопросы
Вы не обязаны знать все аспекты работы всех подчинённых во всех деталях. Поэтому, когда они начнут осознавать сказанное и мапить на свою работу, неизбежно вылезут вопросы и шероховатости. И наличие этих вопросов — хороший знак. Крайне важно поощрить вопросы и грамотно на них ответить. Возможно, вы что-то не учли и кому-то понадобятся дополнительные ресурсы или методологическая поддержка.
Метод появился в компании «Toyota» в 1959 году. К айти имеет косвенное отношение, почитать про него можете в Википедии.
Канбан, как инструмент в IT-менеджменте был представлен Дэвидом Дж. Андерсоном в компаниях Microsoft (2005) и Corbis. А широкое распространение и название, как метод, получил в 2007 году.
В отличие от Скрама, Канбан не слишком строг. Скрам не может применяться частично, если вы используете не все практики, это уже не Скрам. В случае с Канбаном, нет правильного и неправильного Канбана, вы можете использовать те практики, которые вам лучше подходят.
Канбан может применяться не только в айти, но и везде, где есть регулярное производство с повторяемыми этапами, через которые должна проходить каждая задача.
Канбан-доска
Главный принцип Канбана — визуализация при помощи канбан-доски. Рассмотрим её подробно.
Левая колонка — очередь. По-хорошему, надо раз в пару недель проводить встречу по наполнению её задачами, но на практике обычно заинтересованные лица закидывают туда задачи по мере поступления. Можно установить ограничение на максимальный размер очереди.
Правее очереди следует расположить колонки допроизводственных этапов, на которых происходит сбор требований, оценка и утверждение задачи. Дальше идёт черта — точка принятия обязательств. Если задача пересекает эту черту, это означает, что она передана в производство и совершенно точно должна быть сделана и влита в продукт.
Перед последней колонкой вторая черта — точка отдачи обязательств, переход задачи через неё означает, что команда ручается, что с задачей всё в порядке.
Пример канбан-доски с scrumtrek.ru
Количество карточек в каждой колонке, кроме первой (это на ваше усмотрение) и последней, должно быть ограничено реальной максимальной пропускной способностью команды, она определяется экспериментально.
Канбан-доска — не только инструмент визуализации процесса, но и рефлексии. Внимательно рассмотрев доску, можно выявить производственные этапы, которые на самом деле не нужны, и наоборот недостающие этапы. По размеру очереди задач и накалу страстей на битве заказчиков за места в этой очереди, можно определить, насколько «жив» продукт.
Также при помощи этой доски вы можете выявить узкие места, «бутылочные горлышки», в которых скапливаются задачи и замедляют цикл производства.
WIP-лимиты
WIP (work in progress) — это количество элементов, находящихся в работе в настоящий момент. Его не надо путать с WIP-лимитом, ограничением на количество элементов в работе на настоящий момент времени, введённым для достижения некой цели.
Единой формулы для расчёта этого лимита не существует, он подбирается экспериментально. Одно можно сказать определённо — этот лимит вовсе не должен быть маленьким.
Использование WIP-лимита повышает определённость в работе. Потому что чем больше элементов в разных состояниях, тем тяжелее ими управлять и контролировать.
Для того, чтобы посмотреть максимальный WIP-лимит по команде, потребуется отчёт CFD (cumulative flow diagram) или накопительная диаграмма потока.
Пример накопительной диаграммы потока с darvindigital.ru
Каденции
Каденциями называются регулярные встречи при помощи которых вы можете поддерживать и улучшать канбан-процесс в команде.
Канбан-митинг
Пятнадцатиминутная ежедневная встреча. Команда собирается и обсуждает:
Что нам мешает?
Как осуществляется поток работы?
Что мы можем улучшить?
Очень важно обсудить все заторы и затруднения в работе над задачами. Возможно, кому-то из участников нужно оказать помощь.
Встреча по пополнению
Получасовая встреча, проводится раз в неделю. Обсуждаем с заинтересованными лицами, какие новые задачи имеет смысл взять в работу и как переприоритизировать существующие, у них могла поменяться актуальность. Если получаса не хватает, можно общаться и дольше.
Обзор сервиса поставки
Получасовая встреча, раз в две недели. В этой встрече должны участвовать ключевые заказчики, менеджер и представители команды разработки. Обсуждаем удовлетворённость заказчика, показываем метрики, думаем, как же нам улучшить работу команды.
Встреча по планированию поставки
Эта встреча нужна, если у вас есть выделенные релизы. В современных айти-проектах всё чаще используется непрерывная интеграция, когда фичи вливаются в продукт по мере готовности, но всё становится сложно, если у вас есть несколько соседних продуктов и нужно обеспечить синхронность релизов.
Если это так, имеет смысл перед поставкой провести планирование списка фич, которые должны войти в поставку и обсудить, что для этого нужно сделать. Обязательно нужно спланировать мероприятия по обучению пользователей работе с вливаемой функциональностью.
Обзор рисков
Часовая ежемесячная встреча. Имеет смысл собраться со всей командой и обсудить, какие риски появились на горизонте, какие могут сработать, а какие уже сработали и влияют на поставку.
Обзор операций
Это кросспродуктовая встреча, на которой обсуждается межкомандное взаимодействие. Собраться с менеджерами соседних продуктов и обсудить, что мешает делать кросспродуктовые доработки. Раз в месяц достаточно.
Обзор стратегии
Самая редкая встреча, её достаточно проводить раз в квартал. Собираемся с руководством компании, обсуждаем рынок, среду, глобальные вопросы. Ставим цели для команды на квартал. Выявляем стратегические проблемы, корректируем тактику команды.
Метрики в Канбане
Важнейшая метрика в Канбане называется Lead Time — время прохождения задачи от точки принятия обязательств до точки отдачи обязательств. Чем быстрее задача проходит от одной точки до другой, тем команда эффективнее. Кроме того, есть ещё такие метрики:
Cycle Time – время, которое задача находилась в разработке от момента, когда ей начали заниматься, до момента, когда она прошла фазу конечной поставки.
WIP – количество задач одновременно находящихся в работе. Разделяется по разным стадиям работы над задачей.
Wasted Time – время, которое задача проводит в различных очередях, а не непосредственно в работе.
Effectiveness – процент времени, которое тратится непосредственно на работу с задачей, а не на ожидания в различных очередях.
Throughput – количество задач, которое может выполнять команда в единицу времени (день, неделя, месяц).
Делаем правила явными
Нужно проговорить с командой и зафиксировать в виде документа все канбан-правила, которые будут применяться в вашей команде. Особенно важно описать критерии, по которым карточка перемещается из одной колонки в другую и при каких условиях она может быть перенесена обратно.
Хорошо и правильно проговорить с заказчиками правила приоритизации задач. Надо также надо обсудить протоколы, по которым будет проводиться работа со более и менее срочными задачами. Когда людям понятны правила, они готовы и хотят играть работать самостоятельно.
Кейс внедрения канбана в реальной практике
Когда я только начинал практику руководителя разработки, столкнулся с проблемой. Есть внутренний заказчик в виде группы внедрения, есть исполнитель в виде SQL-отдела. От заказчика к исполнителю постоянно поступает поток запросов на SQL-доработки — всевозможные отчёты, скрипты, кастомные импорты. И существует постоянно высказываемая претензия — совершенно невозможно понять, когда та или иная доработка будет сдана.
Оказалось, что отдел использует TFS (сейчас Azure DevOps Server), однако совершенно бессистемно. Кто-нибудь из руководства заводит запрос на доработку, вешает его на рандомного разраба и заказчики ждут у моря погоды. Если какой-то запрос нужен срочно, ответственный внедренец прибегает к руководству департамента и начинает орать. CIO транслирует ор в программиста, он в приоритетном порядке запиливает доработку. Тестировать её некогда, поэтому она сразу накатывается на базу заказчика. Если возникают проблемы, они никак не регистрируются, внедренец просто приходит в отдел SQL, подсаживается к программисту и просит поправить.
Частично этот кейс был рассмотрен в статье «Единая точка входа», но там больше про унификацию входящих обращений, в этой же статье мы поговорим про визуализацию и контроль при помощи канбана.
В первую очередь было принято решение визуализировать очередь. Хотелось использовать веб-приложение, потому что внедренцы крайне не любят ставить сторонние приложения (лол) и вообще, большую часть времени проводят в аутлуке. Выбор пал на trello. Первоочередной задачей стало завести на трелло-доске все открытые запросы на доработку из TFS. Trello тогда умел создавать карточки на основании писем, отправленных на специальную почту, а TFS умел экспортировать воркайтемы в эксель. Мой разраб минут за сорок накидал VBA-скрипт, импортировали запросы.
А вот дальше мы пошли вразрез с классическим канбаном. Вместо столбцов, отражающих этапы работы, мы завели по столбцу на каждого разраба и добавили в эти столбцы карточки запросов, над которыми они работали в данный момент.
Ситуация улучшилась, вместо: «Я не знаю, когда мы сделаем эту задачу», появилась возможность говорить: «Перед этой задачей в очереди ещё шесть задач, сможем взять её в работу после них». Удалось достигнуть договорённости — мы объявляем срок по задаче только после того, как она поступает в работу разрабу, но за этот срок уже отвечаем по полной программе.
Мы стали встречаться со старшим внедренцем два раза в неделю и обсуждать сроки по задачам, взятым в работу, а также положение разных задач в очереди. Так как 80 % задач были от одного и того же заказчика, мы разрешили внедренцу менять очерёдность задач этого заказчика. Если было нужно подвинуть задачи другого заказчика, внедренцы договаривались между собой.
Порядка стало больше, но возникла проблема с приёмкой задач. Так как внедренцы не торопились принимать задачи, их карточки намертво повисали в колонках разрабов, стали копиться внушительные хвосты. Так как решить проблему на организационном уровне не удалось, мы сменили инструмент.
kanbanize.com, в отличие от trello на тот момент поддерживал свимлайны. То есть, можно было завести для каждого разраба дорожку, а колонками сделать уже актуальные статусы, что сильно ближе к нормальному канбану. Кроме того, этот сервис позволял добавить кастомные поля к каждой карточке, что было для нас очень важно, так как кроме TFS-идентифкатора, каждый запрос имел CRM-идентификатор, которыми оперировали внедренцы.
В целом, сочетание организационных мер с правильно подобранным инструментом и методологией, позволили преодолеть кризис и сделать разработку предсказуемой. Негатив от внедренцев закончился.
Предположим, вы или ваше руководство пришло к выводу, что без мобильного приложения бизнес теряет прибыль и обойтись завёрнутым в какую-нибудь программную обёртку веб-сайтом никак невозможно, нужно пилить что-нибудь нативное.
У вас четыре варианта подхода к найму исполнителей.
Инхаус-команда.
Один или несколько фрилансеров.
Аутстаф команда под полным вашим контролем.
Подрядчик, которому вы поручаете работу под ключ.
У каждого варианта есть плюсы и минусы, давайте разбираться.
Инхаус команда
Создаём штатные единицы исполнителей, поручаем рекрутеру найти кандидатов в штат. Вносим им записи в трудовые книжки, платим зарплату.
Вариант хорош, когда приложение планируется очень сложным и дорабатывать его предполагается длительный период (в нынешних условиях «длительно» — это 2-3 года). По деньгам вариант получается чуть ли не самым дешёвым, дешевле только фрилансеры.
Большая ответственность ложится на рекрутера и нанимающего менеджера. Если они наймут недостаточно квалифицированных специалистов, вы потеряете довольно много денег на их зарплаты и урегулирование увольнений без суда (предполагаю, что вы работаете по белому).
Инхаус-сотрудников можно мотивировать корпоративной шизой, давить на совесть, просить переработать во имя будущих бенефитов и применять другие управленческие дарк-паттерны. Во всех остальных вариантах это будет затруднительно или невозможно.
Есть мнение, что инхаус-разработка стабильнее. Что у штатного сотрудника выше мотивация, он внезапно не пропадёт с радаров. Однако работодатели делились со мной историями, как штатный сотрудник просто переставал приходить в офис и брать трубку, даже не забирал трудовую.
Один или несколько фрилансеров
Главный плюс этого варианта — дешевизна. Вы можете найти фрилансеров на совершенно любой бюджет. Даже если у вас буквально три копейки, найдутся люди, которые выполнят заказ и далеко не факт, что некачественно.
Чаще всего, фрилансеры не требуют договор. Есть пространство для бухгалтерских манёвров с расходами на них. Нет официального оформления отношений — в ваших руках большая свобода в формировании команд и их переформатировании.
В остальном же, у этого подхода сплошные недостатки. Например, у фрилансера может быть основная работа, на которой сейчас его не слишком напрягают и у него есть время фрилансить, а через месяц ситуация поменяется. Без договора, фрилансер связан с вами только устными обязательствами и рискует только своей репутацией на данной площадке.
Ранее практиковался найм разработчиков-фрилансеров из Украины, они стоили ещё дешевле, относительно российских. Но теперь этому мешает СВО и препятствия для трансграничных переводов.
За фрилансерами крайне желательно ставить наблюдать штатного специалиста, чтобы он проводил код ревью и добивался качественного, читаемого, поддерживаемого кода. Для того, чтобы когда вам придётся фрилансера заменить, новый специалист не потребовал переписать код с нуля, а мог нормально подхватить недоделанную работу.
Аутстаф команда под вашим контроем
Находите аустаф-компанию, договариваетесь о часовых ставках и грейдах, вам предоставляют специалистов. Вы ставите им задачи, они их пилят и отчитываются в какой-нибудь таск-трекер об отработанных часах. В конце месяца аккаунт присылает отчёт, вы проводите оплату.
Достаточно гибкий вариант. Вы так же, как с фрилансерами, можете формировать и перетасовывать команды как угодно. Если не нравится работа конкретного специалиста, не нужно думать, как его правильно уволить, просто просите аккаунта его заменить.
Недостаток метода в дороговизне. Аутстаферам нужно платить специалистам зарплаты и при этом что-то зарабатывать, поэтому это самый дорогой вариант.
Кроме того, аутстаферы не несут никакой ответственности за результаты и их крайне сложно этой ответственностью наделить. Вы самостоятельно должны их менеджерить, следить за постоянством загрузки и тем, чтобы они делали только приоритетные вещи.
Подрядчик для работы под ключ
Метод подходит для не очень сложных приложений, для которых вы можете составить полное ТЗ и делегировать его производство подрядчику, чтобы он сделал его водопадом за раз, за фиксированный бюджет.
В этом случае ТЗ можно приложить к договору, чётко оговорив критерии качества продукта, который должен получиться в итоге. Возможно, подрядчик захочет написать более детализированное ТЗ и согласовать с вами, на это уйдёт дополнительный бюджет.
Возникает вопрос, как потом поддерживать получившееся приложение. Тут возможны варианты, всё зависит от изменчивости среды и потока изменений. Можно заключить отдельный договор на сопровождение с этим же или другим подрядчиком.
Также возникает вопрос, как в этом случае проконтролировать качество кода с точки зрения последующего обслуживания, развития и доработок.
На практике рассмотренные методы хорошо и правильно комбинировать. Например, нанять инхаус лидов, а для исполнителей использовать аутстаф.
С точки зрения классического менеджмента, худшее, что вы можете сделать — вырастить незаменимого сотрудника. Компания должна быть системой, в которой все элементы заменяемы. Но пока вы маленькие и компактные, никуда от этого не деться, обязательно выделятся лучшие сотрудники, соблазн поручать им всё больше и больше, слишком велик. Да и в целом, когда люди работают у вас относительно долго, скорее благо. Они лучше узнают все нюансы дела, прекрасно разбираются во внутренних процессах и проч. Очень больно, когда они всё же объявляют об уходе.
Любой сотрудник, с которым вы работаете, неважно, ваш подчинённый или руководитель, через какое-то время уволится, либо его уволят. Даже те, которые считаются столпами компании, рано или поздно свалят. Имеет смысл заранее проработать, что вы будете делать в этом случае.
Так как сделать, чтобы ключевые сотрудники не уходили как можно дольше?
Культура
Однажды уборщицу в офисе Аэрофлота спросили, почему она не уволится и не устроится на что-нибудь более денежное, а она ответила: «Вы что! Бросить авиацию?» Но ведь верно. Невозможно организовывать авиаперевозки из офиса с грязными полами, забитыми унитазами, заваленного мусором. Уборщица тоже в авиации, как и ведущий инженер, и гендиректор.
Есть мнение, что деньги — главное. Достаточно платить чуть выше рынка и всё будет хорошо. Это не совсем так.
Культура — штука сложная и многогранная. Сюда входит и доверие, и уважительное отношение руководства к сотрудникам, а также сотрудников друг к другу, и понимание, зачем существует компания, какие её основные цели, своевременная выплата зарплаты, отсутствие сокращений по желанию левой пятки директора, найм правильных людей. И практика показывает, что в компаниях, в которых есть хоть какая-то культура, сотрудники работают долго, даже если зарплаты ниже рынка.
Видение будущего
Люди охотнее работают в компаниях, в которых им показывают и рассказывают про их будущее, хотя бы раз в полгода. Каждый сотрудник, проработавший более-менее серьёзный срок, имеет карьерный трек, знает, чем будет заниматься через год и через пять, знает, каких результатов для этого ему надо достигнуть, какие обучения пройти, какие навыки подтянуть. Для грамотного специалиста это очень важно.
Соответственно, у компании есть стратегия на продолжительный срок, планы развития. Руководство понимает, на какие рынки собирается идти, какие продукты выпускать, как существующие продукты развивать, а также не стесняется на понятном языке доносить эту стратегию до сотрудников.
В общем, если уделять внимание этим двум аспектам, люди будут работать на вас дольше, чем в среднем по больнице. Не вечно, конечно, есть вещи вне контура вашего влияния, но долго.
Аббревиатура SMART появилась в восьмидесятые и её знает любой, сколько-нибудь грамотный управленец. Считается, что все цели должны быть смартовыми, несмартовые цели — это, в целом, и не цели вовсе.
Мне кажется, что одна буква из этой аббревиатуры сильно важнее остальных. Но сначала давайте разберём их все.
Конкретная (specific)
С этим свойством целей я вплотную столкнулся, работая в одной мобильнокодерской компании. PMO меня спрашивает, что будешь делать сегодня для вхождения в проект? Я говорю, почитаю написанную до меня документацию. А он отвечает, что эта цель неконкретная и так формулировать нельзя. Конкретность — это прочитать документы А, B, C, составить список вопросов по ним.
Измеримая (measurable)
Если процессы и результаты не измеряются, процессов и результатов нет, однозначно. «Повысить продажи чапельников» — плохая цель. «Повысить продажи чапельников на 14,5 %» — уже получше.
Достижимая (attainable)
Совершенно бессмысленно, работая в подвале с тремя единомышленниками, ставить задачу, за год перегнать Apple по капитализации, это недостижимо. Зато вполне достижимо разработать и выпустить, например, уникальные чехлы для айфонов и откусить у чехольщиков кусочек рынка.
Значимая (relevant)
То, что вы делаете, должно быть важным, оно должно делать жизнь какого-то сегмента потребителей лучше и/или приносить вам хоть какую-то прибыль. То, что вы делаете, должно быть кому-то нужно. Необязательно миллионам людей, прочтите мой пост про корабль конвоя.
Ограниченная во времени (time-bound)
Лично я не люблю ограниченные по времени задачи, без дедлайна я меньше прокрастинирую, но в общем случае, в рамках бизнеса, надо ставить ограниченные по времени цели. Если увеличить продажи — то не только, на какую сумму, но и за какой период.
А теперь главная мысль этого поста. Самая важная буква в аббревиатуре SMART — R. Значимая. В мире делаются сотни незначимых проектов, которые на самом деле, не нужны заказчику, а пиэм делает их только ради пункта в портфолио. На рынок в результате выходят чудовищные продукты, дающие отвратительный пользовательский опыт и плохо решающие их проблемы, даже если все остальные буквы аббревиатуры учтены при постановке целей.
Вы достигнете истинного дзена, когда научитесь понимать, является ли данная цель relevant и будете делать только значимые вещи в бизнесе и в жизни, не растрачивая ресурсы попусту.
Очень хороший сборник информации по айти-пиэмству, составленный Надей Фирсовой. Особенно интересен входящим в профессию, но будет полезен и более опытным пиэмам.
Ранее я писал о пирамиде принятия решений. Сегодня хотелось бы поговорить об отличиях функционального уровня управления от операционного.
Работа операционного менеджера напоминает работу шахматиста, он двигает фигуры по доске. Имеет доступ к каждому сотруднику, может ставить задачи ему напрямую, контролировать исполнение. Результат работы такого руководителя — результат его команды, сколько законченных функций продукта завершили в единицу времени.
Работа операционного менеджера предполагает детальное погружение в процессы и технические детали продукта, он принимает большое количество низкоуровневых решений. Такой руководитель должен хорошо знать особенности каждого исполнителя, он оценивает, качественно ли работает исполнитель, так как имеет к нему прямой доступ.
С работой операционного менеджера может справиться грамотный специалист-исполнитель после небольшого обучения. Подготовка же к функциональному уровню должна быть намного более серьёзным, потому что на нём подход к управлению качественно меняется.
Работа функционального менеджера уже не подразумевает доступа к каждому исполнителю, потому что их может быть от пятидесяти до ста в разных компаниях. Да, сохраняется доступ к непосредственным подчинённым. В грамотной системе ими должны стать как раз, операционные руководители — тимлид, ведущий аналитик, qa-лид. Но фигуры по доске двигать больше не надо. Надо создавать систему и оттачивать её работу.
Качество системы определяется двумя параметрами:
Предсказуемость выдаваемых результатов.
Способность к самостоятельной работе.
Плохо организованная система проявляет свои недостатки во время больших и малых кризисов. Например, уходит в отпуск ведущий специалист. Работа при этом должна оставаться стабильной и предсказуемой.
Сотрудники, входящие в систему, должны понимать, кто за что отвечает, сформировать такое понимание — тоже задача функционального руководителя.
Главная проблема начинающих функциональных руководителей — они пытаются продолжать использовать операционные инструменты, раздражая операционного менеджера и нервируя команду. Инструменты функционального руководителя — регламенты (с разумной детализацией) и отчёты (желательно, автоматизированные). Также функциональный руководитель должен доносить до всей команды ключевые решения, касающиеся их рабочего уклада, эту функцию лучше не делегировать, информацию непременно исказят.
Результативность работы функционального руководителя не следует пытаться измерять количеством выпущенных регламентов и толщиной отчётов, чтобы ими не пытались прикрывать ручное управление.
Классический менеджмент на этот счёт суров — нет дедлайна, нет задачи. У любой задачи должны быть точки контроля и хотя бы примерный крайний срок.
Насчёт точек контроля, пожалуй, соглашусь. Контроль в начале, в середине и в конце выполнения для каждой делегированной задачи критически важен, когда вы только-только получили должность, без этого вас не начнут уважать. Да и после того, как начнут, контролировать всё равно, надо. А вот с дедлайном всё более спорно.
Есть три основных аспекта, которые сильно влияют на нужность дедлайна.
Творчество и НИОКР
Проблема в том, что сотрудников, выполняющих творческие или научно-исследовательские задачи, дедлайн скорее напрягает. Есть двухсерийный советский фильм «Иду на грозу», там многоопытный завлаб на конференции говорит: «Надеюсь, практические результаты мы получим уже в этом тысячелетии». И научному сотруднику он с порога заявляет: «Не ждите быстрого успеха». Бизнесу такое претит, он всё время норовит навязать исследователям дедлайн, чтобы иметь представление о бюджете, который придётся в эти исследования закопать. Ему больше по нраву конкурент Данкевича, обещающий всё сразу и через четыре месяца, неважно, что у него нет ни подходов, ни методов, один энтузиазм и горящие глаза.
Изменчивость среды
Также имеет значение, изменчива ли среда, в которой делается задача. Меняется среда — меняются параметры задачи, едут сроки. Поэтому в постоянно изменяющихся условиях от жёстких дедлайнов мало толку. Готовность к изменениям важнее следования плану.
Состояние процессов
Имеет большое значение, расписаны ли отдельные подпроцессы, из которых состоит задача. Сколько-нибудь точное прогнозирование дедлайна работает только в условиях ясных процессов. Зато у задач с непрописанными процессами больший потенциал для оптимизации, нужно только в неё погрузиться и понять, что делается неэффективно.
Для остальных задач дедлайны скорее полезны, но надо учитывать индивидуальные особенности тех, кому делегируете ответственные участки задачи.
Для себя отмечаю, что с задачами без дедлайна справляюсь быстрее. Логика такая — всё равно, когда сделать задачу, никто не торопит. Почему бы не сделать её сейчас? А если есть дедлайн, думаю так — до дедлайна есть ещё время, отложу ещё на один день, сделаю потом. Но такое мышление скорее исключение, в целом люди с задачами с дедлайнами справляются быстрее.
