Владимир Бычко об управлении проектами

запихиваем проекты в треугольники

Русская модель управления

Прохоров А. П.
Русская модель управления
М.: ЗАО «Журнал Эксперт», 2002. — 376 с.

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

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

Cкачать

 
 

О результатах работы руководителя

train and win

Несколько слов о том, как становятся менеджерами-снежинками.

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

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

Хороших специалистов часто повышают до руководителей (без учёта остальных факторов это является одной из основных стратегических ошибок).
 
 
Одним из моих первых руководителей был отличный специалист. Он, ещё будучи студентом-дипломником, в одно лицо реализовал для организации систему планирования и выдачи заявок с массой плюшек — права доступа, АРМ диспетчера, отчётность, распечатка нужных документов. В общем, полноценно автоматизировал работу отдела с заявками. Данный специалист отлично проявил себя на средних и больших проектах, после чего получил заслуженное повышение до руководителя отдела, кресло и уютный кабинет.

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

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

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

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

Мудрый гендиректор никогда бы не назначил этого человека руководителем отдела. Он предусмотрел бы для него «горизонтальный рост». Большая, соответствующая квалификации зарплата, интересные проекты, наставничество, консультации. Ведущий специалист отдела, но не руководитель.
 
 
Результатами работы руководителя являются результаты его команды. Основная деятельность:

  • Подбор и мотивация сотрудников
  • Постановка и контроль исполнения планов
  • Грамотное распределение задач
  • Обсуждение, консультации и обратная связь по задачам.

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

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

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

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

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

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

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

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

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

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

Людвиг, «Хитрости и лазейки или Ходячая работа».

 
 
 
Эффективный управленец умеет доверять и делегировать. Он не сидит до ночи за задачами, с которыми могут справиться подчинённые. Потому что этот подход вреден для организации — на деле получается, что работа делается за большие деньги и с худшим качеством (руководители отлично знают, как им постоянно сбивают фокус с задач), чем могла бы быть сделана в случае делегирования. В такой ситуации генеральному директору необходимо провести профилактическую беседу (выяснить причины, вдруг ему на самом деле не хватает людей или ресурсов) и, если это не поможет, либо расстаться с этим менеджером, либо разжаловать в специалисты, чтобы он решал задачи, в соответствии со своей квалификацией не за менеджерскую зарплату.
 
 
Эффективный управленец искренне радуется успехам подчинённых, их росту и результатам, которые были достигнуты благодаря осуществлённой им грамотной организации работ.
 
 
Эффективный управленец должен избавиться от ещё одной вредной привычки — замыкать на себя критичные процессы. Процессы следует выстраивать так, чтобы в случае форсмажорных обстоятельств, отдел/департамент/филиал могли работать без руководителя два месяца без потерь эффективности (если неуправляемый юнит может работать без потерь больше трёх месяцев, возможно, ему не очень нужен выделенный руководитель, но в моей практике таких случаев не было).
 
 
Эффективный управленец требует от подчинённых выполнения задач. Всё просто — он должен быть напрямую завязан на результат. Провалил планы — остался без премии или без работы, поэтому он должен иметь мужество требовать, а если это не работает, то и избавляться от неподходящих сотрудников.
 
 
Напишу ещё пару слов о неподходящих сотрудниках, так как здесь лежит ещё одна ошибка мышления.

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

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

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

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

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

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

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

О менеджере-снежинке

О роли Product Owner в гибкой разработке

О ночных посетителях

Сайт продаёт мебель. Механизма оформления заказа нет, можно только позвонить менеджеру по телефону или написать письмо. Менеджер на телефоне работает с девяти до шести.

Обратите внимание на статистику, объём посетителей с шести вечера до полуночи не уступает дневной посещаемости:
Ночные посетители

Почему это происходит — предельно ясно. Есть сегмент потребителей, предпочитающих на работе работать, а искать мебель вечером или ночью. Часть этого сегмента, заинтересовавшись, позвонит на следующий день, а часть (примерно две трети) забудет или забъёт.

Кейс решается очень легко — форма заказа звонка. Чрезвычайно простой и эффективный инструмент.

Об универсальных инструментах

yesno

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

Бизнес-проблема:
Нам периодически нужно складывать 2 и 7, примерно с той же частотой складывать 9 и 4 и очень-очень редко вычитать 4 из 11.

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

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

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

Четвёртая итерация:
Весьма мощное приложение со сложным интерфейсом и различными режимами — простой калькулятор, инженерный, финансовый, статистический.

Death-Star

Через десяток-другой итераций на выходе получается гигантский программный пакет, умеющий выполнять всё, что угодно. Но почему-то в техподдержку обращаются пользователи клиента, не понимающие, как им сложить 2 и 7, 9 и 4, а также, как вычесть 4 из 11.

Ловушка называется «Трясина Тьюринга». Самые яркие продукты, попавшие в эту трясину: «Nero Burning Rom», «ACDSee», «Qip».

Формальное определение:

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

Другие возможные переводы: яма Тьюринга, смоляной колодец Тьюринга. Дословно: смоляная яма Тьюринга (Turing tar-pit).
Originally: «54. Остерегайтесь трясин Тьюринга, в которых можно сделать всё, но ничего интересного нельзя сделать просто.»

Википедия

 
 
С хабра:

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

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

Тьюринговская трясина на самом деле встречается чаще, чем кажется. И ладно бы в неё затягивало лишь великие академические умы, решающие задачи вселенского масштаба. Но нет — универсальные инструменты стараются создавать все! Каждая программа по записи DVD зачем-то обзаводится своими аудио\видео\фото-редакторами, средствами создания обложек, плеерами и конверторами. Каждый мессенджер считаем своим долгом поддерживать все возможные протоколы связи, вплоть до электронной почты, социальных сетей, СМС, бумажных писем и отправки сообщений внеземным цивилизациям. Все операционки лезут на все типы устройств, каждый кодек-пак включает в себя тонну хлама, документация на некоторые консольные программы имеет по 150 страниц формата А4 и пару тысяч ключей командной строки. Каждый второй сайт в интернете обрастает мхом из погоды\гороскопов\знакомств\работы\чатов\форумов. Стараясь привлечь лишнего пользователя новой фичей, программы и сайты теряют десяток других, которые заколебались выискивать в образовавшейся куче хлама то рациональное зерно, ради которого когда-то эта программа или сайт были выбраны.

Серебряных пуль нет. Лично мне единственным способом не скатится из полезного узконаправленного средства в разрозненный набор малофункциональной чуши кажется система плагинов. Хорошими примерами являются современные браузеры, некоторые онлайн-игры, IDE и другие модульные программы (я уверен — вы сможете дополнить список), которые, оставаясь весьма аскетичными в своей основе, дают тем не менее возможность сотворить боевой комбайн любого уровня сложности.
Перед тем как добавить в свою программу новую фичу — подумайте, а нужна ли она хотя бы четверти пользователей? Если нет — может быть стоит просто вывести наружу API и дать возможность желающим написать и подключить плагин?

Хабр

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

Кнопка создания нового письма, список почтовых папок, окошко мессенджера, поле с заголовками писем. Если есть необходимость расширить функционал, можно подключить модуль из «Лаборатории» или поставить какое-нибудь браузерное расширение.
 
 
Или вот так:
telegram

Тоже ничего лишнего. Разительный контраст с раздувшимся Qip, в контакт-листе которого может быть всё, что угодно, от робота википедии до видео с котиками, плюс 100500 различных протоколов с метаконтактами, которые всё время норовят рассыпаться и требуют периодического причёсывания.
 
 
Также можно сделать такое:
nero
А как болванку-то записать?
 
 
С бизнес-приложениями или специализированным софтом примерно та же история. Не так давно наблюдал автоматизацию крупного производителя. Абсолютно неуниверсальное решение. «Прибитая гвоздями» в процедурах и шарповых сервисах бизнес-логика. Минус — там ничего нельзя перенастроить, покликав мышью. Плюс — скорость работы, устойчивость, нетребовательность к ресурсам и весьма короткие сроки разработки. А если что-либо нужно перенастроить, разработчик может сделать это достаточно быстро.

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

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

Бефстроганов

Бефстроганов

Классическое блюдо русской кухни.
 
 
Минимальный набор продуктов:
   Любое мясо
   Сливки
   Томатный сок
   Чеснок
   Крахмал
   Вода
   Сметана
   Соль и перец.
 
 
Было бы неплохо иметь:
   Зелень
   Немного грецких орехов
   Лук
 
 
Погнали. Первой итерацией готовим компоненты.

Мясо размораживаем (пожалуйста, не делайте это в микроволновке. Если время не терпит, то пусть отлежится в холодной воде, если терпит — вообще без воды, в тарелке при комнатной температуре), затем режем полосками. Солим, перчим, откладываем в сторону.

В стакан льём томатный сок. Кидаем туда измельчённый чеснок, размешиваем. Если есть грецкие орехи и зелень, тоже измельчаем и фигачим туда же. Ставим в сторону.

В стакане холодной воды растворяем чайную ложку крахмала. Ставим в сторону.

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

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

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

В ковшик со сливочным соусом добавляем сметану.

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

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

Традиционный гарнир для этого блюда — жаренная картошка, но ограничился зелёным горошком.

Об интернет-провайдерах

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

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

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

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

Жёлтые объявили об улучшении тарифа. Уже точно не помню цифры, но речь шла о значительном повышении скорости за относительно небольшое увеличение абонентской платы. Сейчас могу соврать, но порядок такой — было 350 рублей за 10 мегабит, предложили 400 рублей, скажем, за 30. Или 50, не суть.

К сожалению, на деле озвученная скорость не достигалась. Ни при скачивании чего-либо, ни на тестах. Иногда 15 мегабит, иногда 9, иногда 20, но очень далеко от заявленной.

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

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

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

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

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

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

speed

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

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

Задача сервиса не в сваливании вины на пользователя, а в своевременном решении проблем.

О переписке

Эффективность методов передачи информации (по убыванию):

  1. Личный разговор у маркерной доски.
  2. Видеозвонок.
  3. Голосовой звонок.
  4. Переписка в текстовом чате.
  5. Email переписка.
  6. Чтение документации.

 
 
Регулярно слышу такие фразы от сотрудников:

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

 
Или такие:

— Разработчик Вася делает не то, что нужно. Я передал ему всю необходимую информацию, а он реализовал совершенно не то.

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

Чтение документации:

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

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

Личный разговор:

— Привет. Я принёс документ с описанием импорта торговых точек из Excel файла. Давай вместе его посмотрим.
— Да, смотрю. А скажи, пожалуйста, вот ты написал, что в поле активности может быть пустое значение. Как его интерпретировать?
— Опаньки. Что-то я об этом не подумал. При импорте новой точки пустое поле означает активную торговую точку (по бизнесу нет смысла создавать точки неактивными), при апдейте существующей торговой точки пустое значение интерпретируется как «не трогать существующую активность». Спасибо за замечание, я немедленно внесу правки.

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

Знаешь, меня всё время бесил один сотрудник. Прочитаю очередное его письмо и аж закипаю, ну как можно писать такой идиотизм!!? Наконец, не выдержал и пошёл к нему на второй этаж. Подхожу, значит, спрашиваю:
— Вот почему ты это написал? Зачем? Что ты имел в виду?
— Вот это, вот это, вот это, вот так и вот так.
— Стоп… Так всё же верно ты говоришь. Так почему же ты пишешь такую ересь?
— Всё я правильно пишу. Что имел в виду, то и написал.

 
 
Совершенно очевидно, что если есть возможность обсудить проблему лично, это стоит сделать. У переписки текстовым чатом, email и технической документации несколько иное назначение, о нём расскажу в следующих постах.

Приоритеты или ресурсы?

Вводная:

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

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

Аналитики работают на два продукта, их ресурсов априори недостаточно.
 
 

Вопрос:

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

Первый вариант решения:

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

Результат: Месячный лаг, негатив от всех клиентов, не заработали ничего.
 
 

Второй вариант решения:

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

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

Вывод:

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

  1. Выяснить наличие ресурсов во всех продуктах.
  2. Взять в работу самый приоритетный запрос на этот продукт.