Автор: Евгений Ефимов
QA Lead, DataArt

Моряки, самолеты и корпорации

• Н.Н. Талеб и моряки.
• Абрахам Вальд и самолеты.
• Левитт и корпорации.

Существует понятие «систематическая ошибка выжившего». Оно встречается в книгах Талеба “The Black Swan. The Impact of the Highly Improbable” («Черный лебедь. Под знаком непредсказуемости» и “Fooled by Randomness: The Hidden Role of Chance in Life and in the Markets” («Одураченные случайностью. Скрытая роль Шанса на рынках и в Жизни»). Он описывает красивую картину, на ней древнегреческие моряки молятся богам во время шторма. Богам нравится, как они молятся? и поэтому моряки спасены. Шторм превращается в штиль или слабый ветер, корабль доплывает до берега, и все остаются целы. Когда спрашивают других моряков, как удалось доплыть, они тоже говорят: «Мы молимся богам и всегда доплываем». Проблема в том, что мы не можем спросить об этом моряков, которые утонули. Возможно, что они тоже молились, но не доплыли. И вообще дело было не в этом, а, т. к. в то время почти все моряки были религиозны, можно предположить, что молились все. И есть вероятность, что это не действует.
Вторая история — про математика и статистика Абрахама Вальда и про самолеты. Действие происходит во время Второй мировой войны. Британские бомбардировщики возвращаются на базу. Задача — понять, где и как укреплять самолеты, чтобы как можно больше возвращалось и как можно меньше падало. Они смотрят на самолеты, которые вернулись, и говорят, что необходимо укреплять наиболее поврежденные попаданиями части. Поскольку в них все время стреляют, мы их укрепим, и все пули улетят обратно во вражеский самолет и всех там перебьют.

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

Стивен Левитт написал интересную книгу «Фрикономика». Он выбрал стандартные книги из серии «10 шагов к успеху» и проанализировал две книги, где рассказывалось про корпорации, использовавшие нововведения, которые привели их к успеху. Эти книги были условно написаны в 2000 году, и корпорации, используя эти наработки, побеждали остальные компании. На момент, когда Левит их анализировал оказалось, что три четверти этих корпораций закрылись. Они оказались убыточными, потому что внешняя среда поменялась, а они не изменили подход к успеху. Соответственно, все эти истории успеха не всегда и не для всех работают.

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

Проекты и конвейеры

• Каждая деталь такая же vs все с нуля.
• Алгоритм и инструкция vs хаос и Agile.
• Зависимость от внешних обстоятельств vs замкнутая система.

В каком же случае мы можем собирать статистику у успешных людей, у которых все получилось? В том случае, когда работаем с конвейером. Когда определенный алгоритм действий гарантированно приводит нас к конкретному результату. Мы сначала кипятим воду, потом кидаем в нее пельмени, ждем, выключаем воду и едим. Сильно отступать от этого алгоритма не имеет смысла. Вряд ли какие-то внешние условия могут помешать. Поэтому, один раз получив какой-то рецепт блюда, план тренировок (то, что мало зависит от внешних обстоятельств), мы можем их использовать. Это как раз отличие проектов от конвейеров.
Есть какая-то конвейерная штука, мы придумали алгоритм, и он работает отлично. Можем отдать роботам, а у проекта принципиально другая суть. Проект — то, что каждый раз делается с нуля, то, что до этого не делалось. Поэтому стандартные алгоритмы у нас могут сломаться в любой момент. Что-то может действительно не работать. И один из важных элементов — зависимость от внешней среды. Если у нас есть более-менее замкнутая система, которая от внешней среды не зависит, мы можем ее алгоритмизировать. В IT-проектах много процессов, решений, задач, которые сильно зависят от внешней среды, от заказчика, от рынка, от команды, от нашей собственной компании и т. д. И, если эта зависимость от внешних обстоятельств сильно перевешивает то, что с системой происходит внутри, алгоритм не поможет. Потому что предсказать все эти внешние обстоятельства довольно сложно.

Как использовать истории успеха

• Классно знать, чем все в итоге кончилось.
• Полный контекст.
• Точки перехода.
• Конкуренты и альтернативная история.
• Выход на метауровень.

Но не стоит совсем расстраиваться по этому поводу, потому что все истории успеха тоже можно использовать. Важно понимать, чем все закончилось. Были фирмы, в которых было ноу-хау, но затем они умерли. Хорошо знать, что у них не получилось, и в какой момент их алгоритм истории успеха перестал работать на них, а также чем все закончилось.
Важно знать полный контекст. Когда кто-то говорит, что он что-то сделал, мы должны понимать, что происходило вокруг в тот момент. К примеру, мы ходим по собеседованиям и спрашиваем у друга: «Расскажи пожалуйста, как ты ходил, как все прошло?» Он отвечает, что пришел и просто сказал, что я Вася Пупкин и его сразу взяли. Ты думаешь о том, как это замечательно, ты просто говоришь, что ты Вася Пупкин, — и тебя берут на работу! Но на самом деле может оказаться, что фамилия директора тоже Пупкин, поэтому это все, что было нужно. И для нас такой вариант не подходит.
Важно понимать точки перехода, когда у нас менялись внешние обстоятельства и, соответственно, в какой момент алгоритмы либо срабатывали, либо не срабатывали. Если мы сможем воссоздать ту же среду, те же условия, скорее всего, тоже сможем пользоваться этими историями успеха. Если у нас не получится ее воссоздать или если мы понимаем, что она поменялась, и там все стало плохо, а у нас поменялось на то же самое, — значит, надо отказываться и искать какие-то другие пути.
Важно послушать истории конкурентов и узнать, что они делали. Возможно, они делали то же самое. Прочитать истории богатых людей или крупных корпораций, у которых что-то не получилось. Есть общие принципы, которые в одном случае приводят к успеху, в другом — не приводят. Мы можем сказать, что эти конкретные вещи на успех как раз не очень влияют.
И хорошо выходить на метауровень. Не просто говорить, что, если всегда будешь надевать шапку, никогда не простудишься. Нужно вывести метаправило: если всегда одеваться по погоде, шансы простудиться сильно уменьшаются.

Как использовать истории неуспеха

• Бери и не делай!
• Хотя на самом деле так же.
• Контекст.
• Конкуренты.
• Мета.

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

Топ 10 ошибок

Я расскажу про топ 10 ошибок, которые совершил.

1 — Кажется я ничего не делаю

• Равномерная загрузка -> Волнообразная загрузка.
• Брать на себя не связанную с ПМ работу.
• Это нормально.
• Совещания — это работа.
• Сам себе менеджер.

Когда я был менеджером по качеству, сколько бы у меня ни было менеджерской работы, часть времени я всегда мог посвятить инженерной. Были дни, когда все восемь часов уходили только на различные звонки, общение с заказчиком, на стратегии и планирование. И все. А если же эти действия заняли два часа, значит, еще шесть я тратил на какую-то инженерию. Я всегда был занят и чувствовал себя неплохим и эффективным работником, который не проедает просто так деньги компании. Когда я стал менеджером проектов, у меня получилось так, что иногда я работаю по 12, 13, 15 часов — потому что нужно много всего успеть сделать, особенно на стартах проектов. А бывают дни, когда я два раза созвонился — и все, и больше нет никаких дел. Начинает казаться, что я ничего не делаю и что недостаточно загружен. Возьму-ка я себе еще один проект. В итоге взял четыре проекта одновременно, и это был коллапс. Загрузка менеджера волнообразная, и, если у тебя длинный период низкой загрузки, тебе поначалу это нравится, конечно. Пару дней чувствуешь себя классно. А потом думаешь: «Нет, ну надо, надо себя занять чем-то, возьму еще проектов».
А потом у тебя спад загрузки меняется на подъем, и конкретно сейчас у тебя 20 часов работы на сегодняшний рабочий день, хотя он всего восемь часов. Нужно четко понимать, что, если у вас периодически не будет работы — это нормально. Если вы занимаетесь менеджментом, если вы все хорошо и классно делаете, то периодически у вас будут куски времени, когда вы не делаете ничего. Сильно боятся и переживать поэтому поводу не стоит, когда вы станете чуть выше уровнем, вы сможете заполнять эти куски разной аналитической работой, развитием отношений с заказчиком, аккаунт-менеджментом. А в самом начале у вас будут относительно свободные куски. Совещание — тоже работа, если вы весь день созваниваетесь — тоже работа.
Если вы вообще ничего не сделали, нет никаких артефактов вашей деятельности, это тоже нормально. Потому что созваниваться целый день и разговаривать со всеми тоже тяжело. С одной стороны, получается, что ты ничего такого не делал, а все равно очень сильно устаешь. И еще одна важная вещь: имеет смысл менеджерить самого себя. Ты сам себе менеджер и ты ставишь задачи не только команде, но и себе. И это тоже — часть твоей работы.

2 — ПМ узкое место

• Ничего не делаю — взвалить на себя все.
• Замкнуть все контакты на себя.

Я стал узким местом, когда мне показалось, что я мало чего делаю, и мне нужно брать на себя побольше всего. Раз у меня есть свободное время, почему бы не помочь Бизнес-аналитику общаться с заказчиком? Я начинаю участвовать в этом процессе! Почему там QA-менеджер общается с заказчиком напрямую? Я и в эту коммуникацию войду! И так далее. И оказался как бы звеном во всех коммуникациях – все, что происходило внутри проекта, проходило через меня. С одной стороны – это довольно-таки полезно, проджект должен быть в курсе всего, что происходит в проекте, но потом получается, что, если ты, например, заболел, устал, появилась срочная работа, которую никто кроме тебя делать не может, ты подставляешь весь проект. Потому что все спрашивают: «А где Вася? У нас такой распорядок, что мы сдаем отчет Васе, а он их пересылает его заказчику! Неужели мы сейчас должны сами его переслать заказчику, и это будет работать?» Короче говоря, плохая штука, старайтесь так не делать. Делегируйте полномочия в тот момент, когда это будет важно.

3 — Интересные задачи

• Инженерное наследие.
• Следить за приоритетом.
• Приоритетом для бизнеса.
• Бизнес сам не всегда в курсе.
• И риски.

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

4 — Лажают все

• Нет безрисковых областей.
• Лажают сеньоры, заказчики и, в первую очередь, ты (это нормально).
• Важно не лажать слишком сильно.
• И не страдать.

Самое страшное, когда думаешь, что этот парень суперкрутой, он всегда все делает правильно, а он вдруг лажает. Ты считаешь, что это парень не ошибается никогда, но правда в том, что, поскольку лажают все, и он то же в какой-то момент сделает что-то не так. Ты думал, что тут бетонная стена, а оказалось все наоборот. В первую очередь, потому что нет безрисковых областей, даже те области, которые вы оцениваете как абсолютно спокойные и свободные от рисков, где вообще не на что напороться, могут взорваться. Например, если вы неправильно поняли требования, если что вы отдали это начинающему разработчику, который в принципе все сделал очень плохо и мало того, что в своей области все сделал плохо, еще и подточил все соседнее, и оно тоже обвалилось.
Взорваться может везде. Лажают сеньоры, лажают заказчики. Кстати, заказчики очень классно это делают, потому что вы договорились, он сказал, что лайки ему не нужны и даже в письме это написал, но реально он не имел это ввиду. В конце проекта он не может его принять, потому что он не может его выгрузить, потому что он пообещал инвесторам лайки, и никому не нужны проекты без лайков. И он честно говорит: «Да ребята, я тоже оказался неправ, но, тем не менее, мы ничего сделать не можем, т. е. вы свободны от ответственности, но конечная цель —выполнить проект, чтобы все были счастливы — не достигнута». И к этому тоже нужно быть всегда готовым. Нужно уметь помогать заказчику, очень аккуратно ему объяснять, уверен ли он сейчас, что мы именно так это должны делать. Если ты только что перешел в проджект-менеджемент, будешь лажать больше всех. Ты будешь, как ахиллесова пята и это тоже нормально. Важно не лажать слишком сильно, важно не делать слишком серьезных ошибок.
Михаил Завилейский, один из директоров DataArt, у которого есть очень много хороших выступлений (их можно посмотреть), рассказывал, что, когда учился в бизнес-школе, там проводили много бизнес-игр, которые прорабатывают разные кейсы и решения близкие к реальности. Он сказал, что секрет успеха во всех этих играх — не придумать самую эффективную стратегию или не придумать максимально безошибочную стратегию, снизив риски до нуля, а просто не ошибиться слишком сильно.
Любая стратегия, которую ты придумаешь, не избавит тебя от ошибок. Следует быть более аккуратным в своих решениях, тогда ты скорее всего выиграешь и выйдешь в плюс. Важно при этом не рефлексировать и не страдать, стараться все проводить в рациональном ключе. Задавать себе вопрос, если сейчас я это сделал не так, как мне лучше в следующий раз сделать все правильно.

5 — Скидка на искажение

• Оценки врут.
• Планы врут.
• Искажения накапливаются.

Следующее что вытекает, из того, что все лажают, это то, что всегда будут искажения. Будут врать как оценки, так и планы. Это не значит, что нужно отказываться от оценок и планов, ничего не планировать, ничего не оценивать и т. д. Про искажения всегда нужно помнить и учитывать их. Еще одна важная вещь —  все эти искажения накапливаются. То есть если у вас программист оценил 10 тасок каждую в час, вы, как хитрый менеджер сказали, что у вас уйдет 20 часов (10 часов у вас в запасе) и первую таску программист сделал за два с половиной часа, это значит, что все он сделает не за 11,5 часов, а за 25 часов. Это значит, что эти искажения будут накапливаться и дальше. Поэтому всегда нужно делать поправки по ходу проекта и смотреть, что происходит дальше.
Тут есть еще один момент: поправку всегда нужно делать в плюс и никогда не нужно — в минус. Потому что программисты привыкли, что менеджеры раздувают их оценки. Чтобы менеджер убедился, что программисты классные, что они хорошо могут оценить время, они могут сказать, что на это уйдет три часа и сделать за час. А на самом деле, эта таска стоила 15 минут. В том, что люди берут в начале проекта, например, построение архитектуры, — довольно много творчества и довольно мало ограничений. Ты реально это можешь сделать быстро, легко и красиво. А переделывать все придется потом, в середине проекта, когда это все будут интегрировать, но сейчас получится — вы поставили что вы неделю будете работать над архитектурой. Архитектура сделана за три дня, и ты начинаешь думать, что можно весь проект сдать гораздо быстрее. Никогда не стоит давать оценки в меньшую сторону.

6 — Микроменеджмент

• Самая токсичная привычка.
• Корень — ощущение некомпетентности.
• Хуже и тебе и команде.
• Есть шанс выставить заказчику неправильные ожидания.
• Есть шанс построить извращенную систему.

Еще хуже ситуация становится, когда вы начинаете заниматься микроменеджментом. Эта проблема также связана с предыдущими примерами. Вам кажется, что вы недостаточно заняты, потом вы понимаете, что все облажались, что все свои таски делают не вовремя и неправильно. И единственное, что вы можете сделать, — подходить к каждому через каждые пять минут и спрашивать, когда все будет готово. Уже готово? Проверил? Ненавидеть вас будут на второй день. Это вредно для вас и для команды. Потому что ты думаешь: «Так, этого я спросил, а этого я спросил, что, господи, уже 15 минут прошло?»
Корень зла здесь — в ощущении собственной некомпетентности. Если ты суперуверен в своих менеджерских способностях и в том, что происходит в проекте, никогда не будешь заниматься микроменеджментом. Когда не понимаешь, что происходит вокруг, у тебя появляется ощущение полной потери контроля, ты пытаешься за всем следить именно за счет микроменеджмента. От это будет хуже всем, в том числе, и заказчику, потому что ты этот микроменеджемент будешь транслировать ему, рассказывая каждые 15 минут, что происходит, что все в порядке, у нас нет проблем. А заказчик потом будет ждать этого постоянно.
Есть шанс построить извращенную систему (sick system). Она не настроена на то, чтобы что-то производить, а направлена на то, чтобы люди не могли из нее уйти, как бы плохо им ни было внутри. Обычно это работает через вину и ответственность, постоянные авралы и обещания хорошей жизни.

7 — Сначала дело — потом отчеты

• Инженерное наследие.
• Реально важно сделать нет времени на фигню.
• Интересно высокая загрузка капитан супермен и т. д.
• Снижается прозрачность.
• Растет напряженность.
• Растет шанс сделать не то.
• Снижается доверие.
• Схлопывается горизонт.

Следующий интересный момент. У вас на работе аврал и ад, нужно добавить еще людей, нужно срочно все починить. Вам нужно постоянно предлагать заказчику лучшие версии, показывать, что у вас есть прогресс. И вы говорите всем: «Давайте работать!» И забываете о таких вещах, как отчеты, JIRA, таски, Burndown и внесение корректировок в план в соответствии с тем что сейчас происходит.
Вы не как менеджер, а как лидер ведете свою команду в бой. Подгоняете и подбадриваете команду. Говорите всем, как важно сейчас доделать все. Постоянно торопите всех: «Что допилил? Давай проверять». Вы договариваетесь с инженерами, которые сервера разворачивают, чтобы все залить и быстро все сделать. В общем, вы постоянно решаете какие-то проблемы. Отчеты? Да и так понятно, что все работают. Все бурлит. Команда включается в авральный режим и выдает невероятную производительность. Командный дух невероятно высок и кажется, что сейчас-то мы заборем все проблемы.
На самом деле, все немного по-другому. Все становится очень плохо, потому что теряется прозрачность. И заказчик не понимает, что у нас происходит. Он видит, что все бегают. А где его продукт и когда все будет готово, ему не очень понятно.
Растет напряженность и внутри команды, и снаружи, особенно со стороны заказчика, если он не видит прозрачной отчетности, него теряется доверие, он начинает сильнее давить на команду. Он давит на команду, команда и так под давлением, в общем, ничего хорошего из этого не произойдет.
В итоге схлопывается ваш горизонт планирования, потому что вы перестали понимать, что сейчас происходит. Вы мыслите очень маленькими категориями конкретных тасков, задач и проблем которые нужно решить сейчас, чтобы все стало хорошо. А какой продукт должен быть через неделю или через месяц, вы уже не видите, горизонт планирования схлопывается. Хотя работать в таком режиме без отчетности и планов, постоянно всем помогая, — очень приятно, лучше так не делать.

8 — Схлопывающийся горизонт

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

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

9 — Баланс помощи

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

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

10 — Предвосхищать ожидания

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

Никогда не обещайте больше, чем можете сделать. Всегда старайтесь обещать поменьше, а делать побольше. Особенно классно, когда вы делаете заказчику, условный подарок. Без проблем соглашаетесь сделать какую-то дополнительную фичу для заказчика, если уверены, что она небольшая и это несложно (еще лучше, если она уже на самом деле сделана).
Например, вы, когда заказчик спрашивает о сроках, обещаете, что завтра все будет готово. Вы могли бы этого не делать, но вы это уже сделали и, если завтра это будет не готово, он расстроится гораздо больше, чем если бы вы ему в этот момент сказали бы, сейчас не получится уже, лучше перенести это в следующий спринт и там все хорошо сделать. А если вы пообещали и не выполнили, это будет выглядеть гораздо хуже. Заказчик расстроится, он, может, всем уже пообещал, что это будет сделано, а потом раз и ничего не получил.
Правилу № 1 — «говорить меньше и делать больше» — нужно следовать всегда, но и тут есть нюанс. Люди, которые заказывают IT, обычно не самые глупые, они этим занимаются и умеют не только слушать, что вы говорите, но и видеть, что вы делаете. Заказчики очень быстро поймут, что, когда вы обещаете сделать что-либо за неделю и каждый раз в среду, в середине недели присылаете готовый вариант, получается, что вам требуется на это три дня. В следующий раз заказчик попросит сделать это за три дня. Поэтому важно не выставлять новых ожиданий.
Есть похожий эффект ожидания с премиями. Например, если вы ежемесячно платите премию сотрудникам в течение полугода в одном и том же объеме, он будет воспринимать ее как заработанную. Не как награду за то, что он хорошо постарался, а как часть своей зарплаты. И если вы через полгода ему ее не заплатите в какой-то момент, для него это будет непонятно. Он спросит вас: «А где моя премия? Я уже к ней привык». Поэтому, если вы не готовы ему поднять зарплату, стоит платить не по 10 000 ежемесячно, а выплачивать в один месяц 20 тыс., в другой месяц не выплатить, а в четвертый месяц выплатить 30 тыс. Чтобы он понимал, что это — разовая премия, и она не бывает постоянной.
Может получиться, а может и не получиться, в зависимости от его действий, либо от финансовых показателей отдела компании. Очень важно при этом рационально проговаривать, почему сейчас есть премия, а в следующем месяце нет. Не нужно просто устраивать лотерею. Но если вы не готовы сделать вознаграждение постоянным, не стоит делать его на средний период. И если вы всегда действительно делаете за три дня, можно делать список задач на завтра и отчитываться перед заказчиком периодически не через три дня, а через неделю. А оставшиеся два дня можно потратить на всеми любимый рефакторинг и еще какие-то полезные вещи.

Автор:

Источник