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

Похвала.

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

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

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

Подарки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Википедия

 
 
С хабра:

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

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

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

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

Хабр

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

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

Тоже ничего лишнего. Разительный контраст с раздувшимся Qip, в контакт-листе которого может быть всё, что угодно, от робота википедии до видео с котиками, плюс 100500 различных протоколов с метаконтактами, которые всё время норовят рассыпаться и требуют периодического причёсывания.
 
 
Также можно сделать такое:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 
Или такие:

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

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

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

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

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

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

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

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

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

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

Вводная:

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

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

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

Вопрос:

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

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

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

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

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

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

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

Вывод:

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

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

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

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

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

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

Нет.

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

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

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

Я считаю рецензии потерей времени.