Попса

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

Категория: Разработка

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

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

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

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

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

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

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

 
 

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

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

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

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

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

 
 

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

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

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

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

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

 
 

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

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

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

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

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

 
 

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

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

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

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

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

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

О социальном капитале

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

Особенно грустно, когда дружественная атмосфера губится руководством. Разберём типичные причины. Исследования, проведенные IBM Institute for Business Value, эти самые причины выявили:
 
 
 

Постоянное рабочее место

Отсутствие постоянных рабочих мест.

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

У меня всегда лежит на столе маленькая металлическая машинка Roadnet Technologies, а на стене висит распечатка слоупока на костылях с подписью «Архитектура комплекса». У соседа сзади — шарики для медитации. У соседа справа — три чебурашки. Ну, вы поняли. Эти милые мелочи крайне важны.

С другой стороны, сотрудников время от времени нужно пересаживать. Нечасто, раз в год достаточно. Это, как раз, способствует наращиванию социальных связей. В питерской компании i-Free столы имеют специальные легко перемещаемые тумбочки, максимально упрощающие «переезды».
 
 
 

Рефакторинг бизнес-процессов

Рефакторинг бизнес-процессов.

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

Минус — он же плюс. Если подойти к вопросу со всей тщательностью, можно напротив, атмосферу улучшить.
 
 
 

Харизматичный лидер

Харизматичный лидер, возведенный в ранг суперзвезды.

Он подчиняет своим интересам всю организацию и нарушает сложившиеся нормы взаимопомощи и справедливости. А как же Стив Джобс, спросите вы? Стив Джобс уникален.

Вы знали, что самые страшные провалы, сопровождаемые многомиллиардными убытками, сокращениями, а в ряде случаев и гибелью компаний, были допущены опытнейшими, образованнейшими, успешнейшими, харизматичнейшими лидерами? Не знали? Читайте «Why Smart Executives Fail» Сидни Финкельштейна, она станет для вас откровением.

Семь привычек потрясающе неудачливых людей
 
 
 

Лицемерие руководителей

Лицемерие руководителей.

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

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

О невозможности

Это невозможно

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

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

А причина одна — некоторые разработчики ленятся. Или не хотят решать «неприятную» задачу. Они же люди.

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

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

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

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

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

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

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

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

 
 

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

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

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

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

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

 
 

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

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

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

 
 
 

Кейс.

 

Вводная

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

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

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

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

 
 

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

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

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

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

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

 
 

Как надо.

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

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

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

О методах мотивации

I can do it

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

Похвала.

Похвала

Сотрудники выполняют работу не за спасибо, это понятно, но всё равно, очень часто произношу фразу: «Отлично, спасибо» (если действительно, есть, за что благодарить). А один из коллег-руководителей говорит: «Спасибо, супер». Это ничего не стоит, но поднимает человеку настроение.
 
 
 

Обращение по имени.

Обращение по имени

Ещё Карнеги писал, что самый приятный звук для любого человека — это звучание его имени. Не так уж трудно запомнить, как зовут всех сотрудников, с которыми постоянно приходится иметь дело. Я всегда начинаю разговор по скайпу с фразы: «Алексей/Сергей/Валера/Женя, приветствую», это тоже нетрудно. Если сотрудников слишком много, действуйте как Герман Клименко, гендиректор LiveInternet — фиксируйте в ежедневнике. Или Evernote Hello, если любите модный софт.
 
 
 

Подарки.

Подарки

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

Прозрачные условия карьерного роста.

 

Карьерный рост

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

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

Критерии оценки.

Критерии оценки

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

Возможность высказаться и быть услышанным.

Возможность высказаться

Очень, очень, очень правильно привлекать сотрудников для решения важных вопросов. Безусловно, решение принимает и несёт за него ответственность директор, но сотрудников нужно привлекать, опрашивать и слушать. Причина проста — руководитель априори не владеет полной картиной происходящего. Вторая причина — сотрудникам очень приятно чувствовать причастность.

В вопросах мотивации, консультироваться нужно обязательно. Например, соучредитель сети «Тонус-клуб» Ирина Чирва предлагает работникам определить 3 показателя, по которым будет оцениваться их работа. Ответы помогают сформировать систему оценки по KPI.
 
 
 

Личный контакт с руководителем компании.

 

Контакт с руководителем

Весьма полезно иногда, подобно Джобсу совершить длительную пешую прогулку и неформально побеседовать с кем-нибудь из сотрудников, можно услышать много интересного. Главное — предупредить об этом сотрудника заранее.
 
 
 

Бесплатный обед в офисе.

 

Бесплатный обед

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

Доска почёта.

 

Доска почёта

Присутствовать на доске почёта в качестве работника месяца приятно даже тем, кто говорит, что абсолютно не тщеславен.

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

Возможность работать удалённо.

Работа из дома

Даже не буду описывать, почему это здорово.
 
 
 

Скидки на продукцию компании.

Скидка на продукцию компании

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

Мотивационный дашборд.

Мотивационный дашборд

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

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

Для разработчиков это может быть диаграмма сгорания во время периода кодинга и информация о количестве активных/исправленных/закрытых дефектов в период стабилизации.
 
 
 

Оплата обучения.

Оплата обучения

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

Копилка клёвых идей.

Копилка клёвых идей

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

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

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
А как болванку-то записать?
 
 
С бизнес-приложениями или специализированным софтом примерно та же история. Не так давно наблюдал автоматизацию крупного производителя. Абсолютно неуниверсальное решение. «Прибитая гвоздями» в процедурах и шарповых сервисах бизнес-логика. Минус — там ничего нельзя перенастроить, покликав мышью. Плюс — скорость работы, устойчивость, нетребовательность к ресурсам и весьма короткие сроки разработки. А если что-либо нужно перенастроить, разработчик может сделать это достаточно быстро.

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

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