?

Log in

No account? Create an account
Andrei Ivanov
Базарное мышление 
4th-Jul-2009 01:21 pm
JetBrains
В бытность мою директором питерского Борланда руководил мною, как-то, индус Радж Шинде. Человек он был неплохой, но не без особенностей. Не любил, например, выражать мысли прямо. Ещё рекомендовал всем читать жульническую книгу In Search of Excellence. Ну, Восток - есть Восток. Как-то обсуждали с ним бюджет на какой-то эвент - новый год, вроде. Мы перед этим с главным нашим бухгалтером все тщательно посчитали, ужали где можно по максимуму, вышло 10 что-ли тысяч баксов. Докладываю Раджу. Сделай, говорит, за 5. Я начинаю рассказывать, почему 10, и почему за 5 не очень получится. Да нет, говорит, ты мне не рассказывай, ты сделай за 5 - и все. Ну, я напористый был директор - убедил. В конце говорю, в следующий раз, говорю, я перед тем как тебе цифру говорить - умножу ее на два. Раз уж ты, вместо того, чтобы слушать аргументы, на два делишь. А он мне отвечает - я, говорит, уверен, что ты так и сделал в этот раз.

Базарный вот этот подход, к оценкам, коммитментам как к предмету торга, очень распространён. Приходит программист к менеджеру, рассказывает результат оценки, а тот ему - сделай в два раза быстрее. Мифы разные по этому поводу гуляют - что надо умножать на два, потому, что поделят на два (как показывает вышеприведённый пример, не такие уж и мифы). Я ещё могу понять (с трудом) когда торговлю разводят по поводу зарплаты при приёме на работу. Сейчас, например, на питерском рынке труда принято предлагать кандидату зарплату на 20% меньше, чем он попросит. Кандидаты соглашаются, говорят. Но торговля по поводу результатов оценки имеет примерно столько же смысла, сколько спор о результате умножения 2 на 2.

Мотивация опытного менеджера, пытающегося выбить оверкоммитмент, понятна. Она является частным случаем стратегии получения большего надоя с коровы при понижении расходов на корм. Известно, что программисты, особенно молодые, склонны с большой ответственностью относится к своим коммитментам, и даже если коммитмент выбит с паяльником, работать по 80 часов в неделю, за ту же зарплату, чтобы с ним встретится. К сожалению, программисты или менеджеры первого уровня также склонны включаться в торговлю. Я как-то слышал советы сходить на рынок и потренироваться, чтобы лучше торговаться при обсуждении оценок. Я бы посоветовал, вместо этого, относится к процессу оценки серьёзно и добиваться уверенности в своей оценке, как в аксиоме. Обсуждать можно соотношение между агрессивностью сроков и риском, но не результат оценки. Хорошая новость заключается в том, что в большинстве случаев, если удаётся направить дискуссию в правильное русло, вышестоящий менеджер соглашается с аргументами и вы приступаете к проекту с реалистичными коммитментами.
Comments 
4th-Jul-2009 09:57 am (UTC)
тут ситуация имхо не в точности оценки, а психологическая проблема - "я заинтересован в работе, а этот доит контору".. так что точность тут не при чем, просто все друг друга подозревают в нелояльности
4th-Jul-2009 10:11 am (UTC)
Я не уверен, что это верно в общем случае, но мне например тем проще защищать точку зрения чем больше усилий я затратил на ее формирование и чем больше я в ней уверен. То есть, если усилия на оценку свелись к вилд-гессу "это займет примерно полгода", то дискуссия типа:
-нет, сделай за месяц
-не меньше пяти
-три
-четыре и по руками
вполне может иметь место.
Если же я потратил пару дней на декомпозицию проекта на части, оценку частей, получение общей оценки - такая дискуссия будет в принципе не возможна.
4th-Jul-2009 10:47 am (UTC)
Очень хорошо в этом смысле помогает скрам. Поделить разработку на маленькие задачи, и выкинуть то, что сегодня не надо. Получается что-то, что как бы работает, ну и хорошо. Когда выпускаем следующую версию, снова поделили на маленькие задачи, не гнушаясь тем фактом, что приходится переписывать заново то дерьмо, что слепили в прошлый раз. И так до бесконечности. С одной стороны, с помощью рыночного подхода сократили разработку. С другой стороны, забыв об экспоненциальном свойстве софтвера. линеаризировали процесс, и обеспечили себе занятость на долгие годы.
4th-Jul-2009 12:18 pm (UTC)
<<Очень хорошо в этом смысле помогает скрам>>
Помогает чему? Подведению теоретической базы под отсутствие плана по срокам и бюджету?
4th-Jul-2009 11:04 am (UTC)
Такая позиция руководства ярко демонстрирует отсутствие доверия к менеджеру. Доверия не на словах, а в действиях. Отсутствие понимания его ценностей и нежелание в них разобраться. В лучшем случае это приводит к утрате инициативы -- если любое действие нужно доказывать, если царит презумпция виновности, менеджер предпочтёт ждать чётких указаний. В более реалистичном сценарии хороший менеджер рано или поздно заебётся и реализует себя в другой компании.
4th-Jul-2009 11:07 am (UTC)
Меня в юности не раз пытались развести на классическую двухходовку:

- Это надо сделать за неделю

- Это невозможно сделать за неделю, получится говно.

- Ну ты сделай хоть что-то, макет, очень надо срочно!

- Ладно, но претензии не принимаются.

- Ты что за говно наваял?!
4th-Jul-2009 12:21 pm (UTC)
Компании, которые не умеют делать быстро, вылетают с рынка. Поэтому позиция менеджмента понятна, она продиктована экономической целесообразностью.
4th-Jul-2009 11:13 am (UTC)
Со всем в статье согласен.
Что касается меня и моих оценок.
То временные оценки я умножаю на 2.4-2.5.
Весь мой опыт говорит о том:
1. Считаем оценку времени разумом. Если ее сказать менеджеру - точно не уложимся из-за различных проблем которые возникают по ходу и от меня мало зависят
2. Умножить на два - в процентах 80-ти будет ошибочно
3. Путем наблюдения лет за 5 выведена цифра 2.3 - 2.4. Они точно выражает в 80 процентах случаях правильное время.

Может сумбурно, но я очень редко попадаю с оценкой времени. Вот в полседнем проекте, ТЗ менялось 2 раза. Но время было установлено жестко. Пришлось сидеть ночами. Сделали почти вовремя. Опоздали на сутки.
4th-Jul-2009 12:00 pm (UTC)
Хочется поспорить с основными антибазарными тезисами.
1. Обосновать можно ЛЮБУЮ оценку. Особенно на не очень типичную задачу, по которой нет интуиции и статистики. Например, систему учета рабочего времени можно сделать и за 2 часа, и за 200 часов, причем с одинаковым функционалом. По задачкам а-ля алгоритмы, оптимизация производительности и т.д. разброс может быть еще больше.
2. Многие разработчики после 25 лет (жизни, а не опыта :) при оценках выбирают максимально комфортный для себя режим работы. Это зачастую существенно меньше 40 часов в неделю.
3. В ходе базара синхронизируется понимание задачи между менеджером и программистом. Случаи, когда программист понял задачу значительно шире, чем она есть, встречаются очень часто. Особенно, когда ТЗ нет по той причине, то написать ТЗ сложнее, чем код.
4. Многие оценки, приносимые программистами (с некоторым обоснованием), таковы, что теряется экономический смысл от решения задачи. Так что базарить и искать компромиссы приходится исходя из здравого смысла.
4th-Jul-2009 12:32 pm (UTC)
Чтобы человек работал в некомфортном для себя режиме, у него должна быть очень сильная мотивация. А главное - это не нужно. Это бывает нужно, действительно, в самом начале существования стартапа, когда надо продемонстрировать макет, чтобы люди видели, за что дают деньги. Если начинается аврал и штурмовщина потом, это мы что-то просрали, когда занимались планированием, так не надо. В жопу трудовой подвиг.
4th-Jul-2009 01:18 pm (UTC)
А мне кажется, что это следствие того, что во многих местах менеджер - это единственный career path для программиста. Как сделать программисту карьеру? Начальник же видит две метрики - 1) много работает 2) не проваливает дедлайны. Работай по 80 часов, тебя заметят, станешь менеджером, будешь мало работать и много получать. Получившийся "менеджер" никаких других способов управления, кроме заставить больше работать просто и сам не знает.

Ну вот как бы если водителем собачей упряжки назначали самую крупную собаку...
4th-Jul-2009 01:30 pm (UTC)
зачем менеджеру избавляться от работника который хорошо работает повышая его? такое возможно только если менеджер поднимается ступенью выше и тогда он берет с собой хорошо работающего повышая его так же на одну ступень
4th-Jul-2009 06:02 pm (UTC)
Если удаётся направить дискуссию в правильное русло, вышестоящий юзер соглашается с аргументами и вы приступаете к посту с реалистичными комментами!
4th-Jul-2009 11:20 pm (UTC)
Мне всегда нравится, когда на такие заявления кто-нибудь начинает упорно возражать. Помню, кто-то тут доказывал, что оценки перформанса работников непременно должны быть распределены по Гауссу. Ибо - как же иначе? Я не к тому, что такие люди непременно не правы, просто - новые миры открываются.
5th-Jul-2009 11:28 am (UTC)
Я понимаю, в принципе, откуда возникают возражения. Практически для любого примера "плохой менеджер - бедный разработчик" и соответсвтующей проблемы существует на практике пример "плохой разработчик - бедный менеджер" относящийся к той же проблеме.

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

Другое дело, что я не пишу про "плохих разработчиков" или про "плохих менеджеров", как меня иногда читают. Я пишу про проблемы общения, в основном.
This page was loaded Nov 20th 2017, 11:47 am GMT.