Надпись на «Post hoc non propter hoc» на картинке переводится с латыни как: «После не означает вследствие». Общеизвестно, что причины провалов нужно тщательно исследовать, как бы ни был провал неприятен, а причины его глупы. А вот причины успехов — нет.

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

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

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

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

У прочитавших пост о группе управлении разработкой закономерно возникнет вопрос — почему я не упомянул о команде тестировщиков и QA лидере?

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

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

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

Возможны три подхода к организации группы тестирования:

1. Выделенный департамент тестирования, обслуживающий все продукты.
2. Тестировщики как части универсальных кросспродуктовых команд.
3. Тестировщики как части микрокоманд.

Выделенный департамент тестирования.

Все тестировщики выделены в обособленное подразделение, которое проводит тестирование всех программных продуктов, выпускаемых компанией.

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

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

Тестировщики как части универсальных кросспродуктовых команд.

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

Тестировщики как части микрокоманд.

Почти идеальный подход. При старте доработки формируется микрокоманда из аналитика, нескольких разработчиков и тестировщика. Микрокоманда ведёт производство на всех этапах, от сбора требований, до финальной сдачи заказчику (вливания в релизный билд в случае продуктовой разработки). Тестировщик микрокоманды находится в курсе требований с самого начала и готовит план тестирования с момента передачи требований разработчику, а не по готовности доработки, что позволяет тестировать комфортно, оперативно и эффективно.

Для того, чтобы руководить разработкой продукта, нужно уверенно держать в руках три «руля»:

1. Административное руководство.
2. Управление изменениями.
3. Техническое и архитектурное управление.

 
 
Рассмотрим все три «руля» более подробно.

Административное руководство.

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

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

Организация — процессы, напрямую не связанные с производством, но влияющие на него. Инфраструктура (рабочие места, обеды, кофе и проч.) и обеспечение коммуникаций.

Кадры — рекрутинг сотрудников, мотивация.

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

Данного перечня работ вполне достаточно для полной загрузки менеджера продукта. При попытке навесить на него второй и третий «рули» возникнет сбивание фокуса и падение производительности всей команды.
 
 

Управление изменениями.

Разработчики пишут код по техническим заданиям/требованям, которые должны быть собраны, проанализированы и формально описаны. Кроме того, необходимо на протяжение всей работы над продуктом не упускать из внимания vision — общую концепцию, идею. Сюда входят следующие работы:

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

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

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

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

Техническое и архитектурное управление.

Сюда входит группа работ по обеспечению производства. А именно:

Архитектурное управление — обеспечение технической целостности и непротиворечивости работы модулей системы, структуры базы данных и проч.

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

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

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

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

Консультации аналитиков, выработка вариантов реализации.

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

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

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

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

Не фиксировать договорённости.

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

Самый простой способ фиксации договорённости — отправить всем участникам встречи резюме разговора. Традиционно это делает организатор встречи.

Итак. Встретились, обсудили, пришли к договорённости, отправили емейл с подтверждением.
 
 

Брать глупых трудолюбивых людей.

Люди бывают умными и глупыми, ленивыми и трудолюбивыми.

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

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

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

Такой человек — катастрофа для бизнеса, его место на госслужбе.

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

Итак. Умные лентяи — наш выбор.
 
 

Брать людей, ранее работавших в государственных компаниях.

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

Итак. Никаких бывших госслужащих.
 
 

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

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

Итак. Не верим сказанному на собеседовании, берём рекомендацию лично.
 
 

Брать нелояльных профессионалов.

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

Итак. Лояльность важнее профессионализма.
 
 

Делегировать найм сотрудников.

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

Итак. Людей нужно брать самому.
 
 

Не давать второго шанса. Давать третий.

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

Итак. Даём второй шанс, но не даём третьего.
 
 

Ненужные заказы и ненужные люди.

Не стоит брать заказ, если заказчик использует следующую риторику: «Сделайте это в убыток себе, зато потом мы обеспечим вам вал дорогих заказов». Не обеспечат, это развод. Аналогично не стоит брать убыточные заказы ради опыта (зачем вам опыт просирания денег?) или ради портфолио.

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

Итак. Избегает ненужных заказов и ненужных людей.
 
 

Бороться с недостатками вместо развития достоинств.

Классика. Линкольн поставил командующим Гранта, имеющего серьёзный недостаток — пристрастие к бухлу, зато умеющего мастерски планировать операции. Грант победил «сбалансированных» командиров штаба генерала Ли, не имеющих серьёзных недостатков.

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

Итак. Развиваем достоинства вместо борьбы с недостатками.

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

Данный кейс полностью решает проблему: «А в какой папке лежит этот блджадский договор, не помню когда заключённый с Иваном Никифоровым?».

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

Поступил документ — берём этикетку с номером, присобачиваем к первой странице. Если документ многостраничный, расшиваем, сканим на хорошей МФУшке, тут же делаем pdf и кидаем в эвернот.

Заранее заводим экселевский файлик, в котором прописываем колонку с входящими номерами. По мере поступления, вписываем названия документов и сопутствующую информацию в ячейки напротив номеров. Советую не делить файл на листики в зависимости от типа документа, а завести отдельную колонку для типа — потом будет проще анализировать, плюс сквозная нумерация. А вот для исходящей документации отдельный листик вполне можно завести.

По привычке пишу «экселевский», но лучше использовать гуглодокументы — там удобнее организована совместная работа.

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

Крайне желательно иметь премиум аккаунт, чтобы этот процесс могли осуществлять несколько человек.

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

Руководитель небольшой компании (до 30 человек) должен хотя бы раз в две недели устраивать короткие (до 10 минут) встречи с каждым сотрудником. Причём, эти встречи не должны быть посвящены отчётности (Что делал? Что сделал? Что делаешь?), а проходить в свободной форме (Какие есть идеи? Что можно улучшить? Что думаешь насчёт всего?).

1. Повышает вовлечение сотрудника.
2. Позволяет получить обратную связь.
3. Некоторые идеи могут оказаться здравыми.

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

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

Искренне жаль, что многие руководители об этом забывают.

Человек, желающий стать сильным менеджером, должен играть в компьютерные игры. Причём, речь не о «Косынке» и не о злых птичках, а о серьёзных MMORPG.

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

В MMORPG не существует такого понятия как «проблема». Любой квест, даже самый сложный (в качестве примера можно привести цепочку WOW квестов на получение легендарного топора «Тёмная Скорбь». Для того, чтобы справиться с этой цепочкой, нужна работа целой гильдии в течение нескольких недель, однако владельцы «Тёмной Скорби» существуют, хоть и в небольшом количестве), является лишь задачей, которую можно решить. Для этого может потребоваться потратить время на прокачку персонажа, разжиться дополнительными ресурсами, привлечь партнёров по гильдии или случайных попутчиков, но решить его можно всегда. Формирование такого мировоззрения крайне полезно — в работе можно столкнуться с огромной и страшной проблемой, но её можно разрешить, если воспринимать как квест.

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

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

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

Словом, играйте и не считайте это время потерянным.

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

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

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

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

Я верю, что есть гении, которым всё это не нужно и которые способны, скажем, взять и написать гениальный код. Самообразование, природные способности и всё такое. Однако реалии производства таковы, что основную ценность имеют те, кто способен постоянно писать не гениальный, а работающий код. Восемь часов в день, сорок в неделю. А сложные и интересные задачи бывают не всегда. Бывает необходимость и пару значений в сотне документов скриптом поменять, и простую табличку с процедурой заполнения запилить, и пару показателей в отчёт добавить. И при этом нельзя говорить, что скучно, неинтересно или просто влом. Нужно взять и сделать. Будет ли справляться человек, которому было влом сидеть на парах в ВУЗе? Не уверен.

90 % работы для программиста — это корпоративное ПО

Основы экономики: цена чего-угодно (включая вас) — это функция спроса и предложения. Давайте сначала посмотрим на спрос. Большинство ПО не продается в коробках и не доступно для скачивания в интернете или App Store. Большинство ПО — это тоскливые узкоспециальные корпоративные приложения, поддерживающие глобальную экономику со всех вообразимых сторон. Эти приложения подсчитывают издержки, оптимизируют расходы на пересылку, помогают составлять бухгалтерские отчеты, проектировать новые интерфейсы, вычислять цену страховки, помечать подозрительные заказы для ручной проверки и т.д. ПО решает проблемы бизнеса.

ПО решает проблемы бизнеса несмотря на свою душераздирающую скучность и отсутствие технологической сложности. Например, представьте себе электронную форму отчета о командировочых расходах. Для компании размером в 2000 человек она может сэкономить порядка 5000 человеко-часов в год в сравнении с ручной обработкой бумаг, что при средней стоимости часа работы в 50 $ сэкономит 250 000 $. Компании все равно, что это самое примитивное на свете CRUD-приложение. Единственное, что имеет значение, это то, что оно сокращает издержки или генерирует прибыль.

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

«Перестаньте называть себя программистом и другие карьерные советы»

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

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

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

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

• Слишком много активных чатов. Лишь некоторые из них действительно полезны, в остальные достаточно изредка заглядывать, но уведомления утомляют.
• Трудно найти старый групповой чат, в котором была достигнута какая-то договорённость.
• Контакт-лист становится реально огромным.
• Даже в рамках хистори одной переписки трудно найти нужное место.
• Некоторые люди очень долго не отвечают.
• Некоторые сотрудники используют вместо фотографий изображения котов, енотов, гербов, хохлов. По фамилии человека не всегда можно опознать, приходится несколько секунд гадать, из какого отдела этот кот или енот.

Полезные советы:

• Выучите команды /alertsoff и /alertson. Первая выключает уведомления о новых сообщениях в данном чате, вторая включает. Требуется на случай, когда обязательно нужно висеть в каком-то чате, чтобы видеть инфу по необходимости, но реагировать не нужно.
• Создаёте групповой чат — сразу же присваивайте ему имя, соответствующее теме беседы. Я ещё и картинку присобачиваю, но это лишнее. Тема закрыта — архивируйте переписку и удаляйте чат. Если в контакт-листе есть неперименованные чаты — удаляйте.
• Все имена контактов должны быть в едином стиле. Лучше всего — Фамилия Имя. Также нужно добавлять к имени короткий тег, например #market, #admin или #coder на своё усмотрение. Очень сильно облегчает узнавание человека, с которым общаетесь редко.
• В скайпе есть странные стандартные смайлики неясного назначения, например, звёздочка. Так вот, их назначение — маркировка важного момента в длинной переписке. Например, достигли договорённости — сформулируйте её ещё раз и поставьте в начале фразы звёздочку — потом будет легко отыскать.
• Если есть возможность не писать текстом, а позвонить войсом — звоните. Если есть возможность видеосвязи, демонстрации экрана — обязательно пользуйтесь.
• Если во время голосового обсуждения достигли какой-либо договорённости, немедленно дублируйте её текстовой строкой в чате. По правилам делового общения, после такого обсуждения организатор высылает участникам резюме встречи, если дублировать устные договорённости текстом по мере разговора, это сильно ускорит написание резюме.
• В чате были написаны некие важные данные — немедленно дублируйте их в основную систему хранения информации (эвернот, закладки браузера, таск менеджер, что угодно). Не забывайте, что хистори в скайпе синхронизируется через задницу, при установке скайпа хистори нужно копировать руками. И вообще, присмотритесь к Viber — перспективная штука.
• Я вас умоляю, используйте в качестве аватара свою фотографию, причём в виде лицевого портрета без головного убора. Хотя бы для служебного акканута — в личном может быть всё, что угодно. Имеете что-то против — разместите логотип компании, но не зайчиков, котиков, анимешных персонажей и прочей ерунды. Во-первых, это совершенно неуместно, а во-вторых, ухудшает узнаваемость.

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

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

Результат:

1. Менеджер не владеет точной информацией о текущей загрузке разработчиков и не может нормально планировать.
2. Разработчиков часто дёргают, не дают уйти в поток.
3. Внедренцы конфликтуют из-за разработчиков.
4. В первую очередь делают запросы тех, кто «громче кричит», а не те, которые стратегически более важны.
5. Сроки срываются, очередь копится, организация теряет деньги, клиенты нервничают.

 
 
Приведённый ниже подход снижает скорость, но повышает предсказуемость разработки:

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

Подробнее о работе с очередями можно прочитать в посте «Об очередях».