Попса

популярный светский альманах

Тег: менеджмент

О матрице взаимных ожиданий.

Expect the unexpected

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

Ожидания разработкиОжидания тестированияОжидания внедрения
Обязательства разработки Олли Мяяття:
Осси Вяанянен:
Лассе Кукконен:
Сами Сало:
Теему Селянне:
Олли Йокинен:
Обязательства тестирования Яркко Иммонен:
Петри Контиола:
Лаури Корпико:
Сами Сало:
Теему Селянне:
Олли Йокинен:
Обязательства внедрения Яркко Иммонен:
Петри Контиола:
Лаури Корпико:
Олли Мяяття:
Осси Вяанянен:
Лассе Кукконен:

 
В примере три отдела — разработка, тестирование, внедрение. В каждом работает по три сотрудника:
Разработка: Яркко Иммонен, Петри Контиола, Лаури Корпико.
Тестирование: Олли Мяяття, Осси Вяанянен, Ласси Кукконен.
Внедрение: Сами Сало, Теему Селянне, Олли Йокинен.
 
Таблица расшаривается на всю компанию. Это важный момент — заполнить её должны не только руководители подразделений, но и сотрудники. Каждый сотрудник пишет, что именно он ожидает от других отделов.
 
 
После заполнения может получиться следующее:

Ожидания разработкиОжидания тестированияОжидания внедрения
Обязательства разработки Олли Мяяття:
Основной поток должен работать без ошибок на компьютере разработчика.

Осси Вяанянен:
Передаваемый код должен быть покрыт модульными тестами.

Лассе Кукконен:
Передаваемый код должен содержать комментарии.
Сами Сало:
Соблюдение сроков разработки, предоставление пояснительной записки.

Теему Селянне:
Быстрое исправление дефектов, обнаруженных заказчиком.

Олли Йокинен:
Умение проводить доработки, взаимодействуя с внедренцем напрямую.

Обязательства тестирования Яркко Иммонен:
Своевременное предоставление тестовых планов.

Петри Контиола:
Участие в выработке варианта реализации.


Лаури Корпико:
Своевременно давать фидбек по протестированной доработке.
Сами Сало:
Передавать только доработки, не содержащие дефектов.

Теему Селянне:
Не затягивать тестирование.

Олли Йокинен:
Умение быстро выявлять причины дефектов, найденных заказчиком.

Обязательства внедрения Яркко Иммонен:
Предоставление грамотных ТЗ.


Петри Контиола:
Своевременные ответы на вопросы в процессе разработки.

Лаури Корпико:
Быстрые темпы приёмки.
Олли Мяяття:
Внедренец, обращающийся с возможным дефектом, должен предоставить грамотное описание этого дефекта.

Осси Вяанянен:
Внедренецы должны принимать участие в регрессионных тестах.

Лассе Кукконен:
Внедренцы должны обеспечивать обратную связь после передачи протестированной доработки.

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

ОтделОбязательствоПоказательПлан
Разработка Основной поток перед сдачей на тест работает на компьютере разработчика без ошибок. Количество замечаний тестировщика но ошибкам в основном потоке в доработках, сданных на тест. (Фиксируется в задаче на тестирование). Количество замечаний по ошибкам в основном потоке за месяц/Количество доработок за месяц не более 0,3.

Пример:
10 доработок в месяц, 5 ошибок. Факт = 5/10 = 0,5, план не выполнен.
10 доработок в месяц, 2 ошибки. Факт = 2/10 = 0,2, план выполнен.
Передаваемый код должен быть покрыт модульными тестами.Процент покрытия процедур модульными тестами. (Фиксируется в задаче на тестирование)Среднее покрытие процедур модульными тестами не ниже 90 % в месяц.
Доработки должны сдаваться в срок.Разница между датой дедлайна и датой передачи доработки заказчику (Фиксируется автоматически по закрытию задачи на сдачу заказчику) Среднее отклонение фактических дат от плановых не выше корня квадратного от среднего количества плановых дней на доработку.

Пример:
В среднем, 9 дней на доработку по плану. Среднее отклонение от плана: 2 дня. sqrt(9)=3; 3 меньше 2, план выполнен.

Дефекты, пришедшие от клиента должны закрываться максимально быстро.Среднее время закрытия дефекта. (Фиксируется в дефекте)Среднее время закрытия дефектов с признаком «дефект от клиента» не больше 2 рабочих дней.
ТестированиеСвоевременно предоставлять тестовые планы.При передаче требований в работу, к задаче на разработку должна быть прикреплена ссылка на тестовый план.Процент покрытия передаваемых доработок тестовыми планами не ниже 95 %
Передавать внедренцам только доработки, не содержащие дефектов в основных и альтернативных потоках.Количество дефектов от клиента на протестированные данным тестировщиком доработки. Отношение количества дефектов от клиента на доработки данного тестировщика к количеству переданных доработок не выше 0,3

Пример:
10 доработок в месяц, 5 ошибок. Факт = 5/10 = 0,5, план не выполнен.
10 доработок в месяц, 2 ошибки. Факт = 2/10 = 0,2, план выполнен.
Тестирование должно проводиться максимально оперативно. Среднее отклонение фактических дат от плановых. Среднее отклонение фактических дат от плановых не выше корня квадратного от среднего количества плановых дней на доработку.

Пример:
В среднем, 9 дней на тестирование по плану. Среднее отклонение от плана: 2 дня. sqrt(9)=3; 3 меньше 2, план выполнен.

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

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

Подобный подход способен решить массу внутренних проблем и конфликтов.

О рычагах власти

respect my authoritah

Рычагов или источников власти ровно пять. Вот они:
 
 

Правовая власть

Правовая власть, «уставщина»

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

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

 
 

Поощрительная власть

Поощрительная власть, «пряники».

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

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

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

 
 

Принудительная власть

Принудительная власть, «кнуты».

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

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

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

 
 

Экспертная власть

Компетентная власть, «эксперт».

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

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

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

 
 

Харизматическая власть

Харизматическая власть, «батяня».

Есть руководители, под началом которых просто приятно трудиться из-за совокупности их личностных качеств и харизмы. «Юлия Анатольевна — наше солнышко», — говорят про таких руководителей.

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

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

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

О псевдобюрократии

Бюрократ за столом
 

Глубинная причина возникновения дурной бюрократии

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

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

Это происходит ровно до того момента, пока сотрудник не окажется на позиции, спектр обязанностей которой ему будет не по зубам. Эта позиция называется «личный предел некомпетентности».

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

 
 

Основной признак истого бюрократа.

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

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

Подробнее о дурной бюрократии читайте в книге «Законы Паркинсона».

Но есть и другая форма бюрократии.

 
 

Правила полезной бюрократии.

Базовое правило: Каждый участник процесса должен точно знать, зачем процесс существует и почему он проводится так, а не иначе.

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

 
 
 

Кейс.

 

Вводная

В организации принят следующий порядок обработки запросов на изменение: регистрация, приоритезация, оценка аналитиком, согласование оценки, написание/корректировка требований, передача в работу, актуализация требований, сдача заказчику.

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

Цель достигнута? Да. Функционал работает так, как надо, правку провели очень быстро (там десяток строк кода, не больше). Всё было бы хорошо, если бы эти два специалиста существовали в вакууме, где кроме них и продукта никого нет.

Затраты — пять минут на разговор, двадцать минут на правку и заливку.

 
 

Последствия.

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

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

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

Потери на абсолютно бессмысленную работу — около 6 человекочасов всех участников.

 
 

Как надо.

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

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

 
 
Грамотно организованная бюрократия экономит время, предотвращая потери в будущем.
 

Две книги об управлении

А. Краковецкий: «Когда я говорил…»

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

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

Скачать

М. Абрашофф: «Это ваш корабль»

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

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

Скачать

Электронная версия книги Александра Краковецкого распространяется бесплатно, но если хотите поблагодарить автора, это можно сделать с помощью Webmoney:

  • R102450157338
  • U294775396951
  • Z125904892630

О группе управления разработкой

team

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

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

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

team

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

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

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

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

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

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

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

team

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

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

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

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

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

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

team

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

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

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

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

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

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

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

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

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

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

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

О менеджерских ошибках

fatal error

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

О периодических встречах

Need to meet more often

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

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

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

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

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

Об играх

You remember when we would play Life with you was a beautiful game.

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

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

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

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

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

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

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

Единая точка входа

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

Бардак

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

Результат:

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

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

Корректная организация работ

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

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

Руководство к своду знаний по управлению проектами

Сегодня мне хотелось бы поделиться настольной книгой любого профессионального проектного менеджера.

На всякий случай, дополнительная ссылка на скачивание.