Как стать автором
Обновить

Комментарии 22

Не слишком ли много времени будет уходить на обсуждение?
Смотря какая задача. Я предпочитаю долго обсуждать и быстро делать.

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

До сих пор встречаю среди современных консультантов по управлению «новоявленные методики», описанные еще в 70-х года отечественными социологами. Слишком многое мы выкинули, как «само собой разумеется неправильное», только потому что это применялось в СССР, даже не углубляясь в детали.
Извините, что через 10 лет спрашиваю ) Но можете указать на те самые методики применявшиеся в СССР и теперь объявленные «новыми». Хотелось бы изучить.
Любые не монетарные методы. Например профессиональные категории: Слесарь 1-го разряда или Джуниор-программист. Только про джуниоров и сеньоров знают уже все, а о том что эти категории введены для того чтобы специалист проходил постоянное обучение и аттестацию с целью повышения квалификации вспомнили или догадались не многие.

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

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

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

Сейчас это подается как “мы создаем лучший продукт”, “наша компания спасет мир от загрязнения” и т.п.
Спасибо. У меня вот в инструкциях осталось от советских времен… «категории 1-4 для программистов», написано что должна аттестовать комиссия. Но оба моих начальника сказали, забей, у нас тут нет людей чтоб вас аттестовать. А так действительно движения по лестнице на ФГУП нет, ты студентом придешь и будешь техником-программистом, а с дипломом будешь инженером-программистом, ну может вырастешь до руководителя группы, а потом до начальника бюро, но начальником отдела уже не станешь.
А с категориями было бы здорово, человек бы стремился к улучшению, зная о поощрении материальном если категорию открыл. Интересно, что на производстве это осталось для рабочих, например у работников ОТК и токарей есть разряды, они за них получают разные зарплаты. А программисты — так программисты. В итоге каждый ходит и лично выбивает себе ЗП, а мотивацию приходиться из энтузиазма личного черпать.
Мотивация тут не причем. Главное чтобы человек мог объяснить как он это будет делать. Когда он будет знать как он сделает, он будет знать и точный срок.

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

А заказывать разработчику задачу, которую он не знает как решить, это уже венчур :)
Во-первых, как сказали выше, куча времени будет уходить та тупую болтовню. Причем «куча времени» — это еще слабо сказано! Если заявляется, что такой подход поможет заказчику лучше контролировать стоимость (через количество часов) — то резонно предположить, что он таки будет это делать. Соответственно получаем испорченный телефон «заказчик-менеджер-прогер», в котором прогеру постоянно надо объяснять заказчику (дубу) через менеджера (тоже дуб) почему ХХХ делать именно 90 минут а не 15.

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

Далее — момент, что всю ответственность (в плане оплаты за работу) несет программист, который если вылез за оговоренное время — то ничего сверху не получает. Это, с одно стороны, правильно — будет его мобилизовать. А с другой — такой подход 100% приведет к сильному завышению сроков, особенно на задачах, которые вот прям так сразу и непонятно как делать (вариант: как лучше делать). А завышение приведет к новой волне споров типа «а че так долго??».

Итого метод — от реальности оторвано ну очень сильно! Работать если и будет — то только на очень-очень простых задачах, которые можно сходу точно оценить.
«Далее — момент, что всю ответственность (в плане оплаты за работу) несет программист, который если вылез за оговоренное время — то ничего сверху не получает.»

перечитайте:
«Если разработчик не уложился в установленные им же самим сроки, он получает сумму в обговоренном размере стоимости часа за! фактически! потраченное время.»

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

Вкратце это выглядит так.
«Угадай число, которое я задумал» – такую игру я уяснил на одном из моих первых проектов, когда был ещё молодым программистом. У пользователя или руководителя высокого уровня есть своя «приемлемая» оценка для сроков, бюджета и/или других аспектов переговоров, но они отказываются чётко её сформулировать. Когда менеджер проекта предлагает свою оценку сроков и бюджета, пользователь или руководитель попросту качает головой и говорит: «Нет». Такой ответ подразумевает: «Это слишком много – попробуй угадать ещё раз». Незадачливый менеджер в конце концов (иногда после полудюжины попыток!) приходит с нужной оценкой, но поскольку теперь это его оценка, ему впоследствии и придётся отвечать за неё.
Если программист (исполнитель) не чувствует себя уверенным настолько, чтобы продвигать свои оценки и пре необходимости даже давить на заказчика в оценке сроков, настаивая на правильности, то вскоре он падет жертвой подобных игр. Это неприятно.

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

Дельное замечание, спасибо! Особенно за книгу, которую не могу теперь нигде найти в продаже :)

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

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

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

У меня даже тест есть такой для отбора претендентов на должность монтажников — обьяснить как они будут вешать ящик.

Варианты ответов:

Вася:
— Ну, это, возьму и повешу.
— А что вы сделаете сначала?
— Ну сначала я это, прикручу ящик.
— А отверстия для анкеров когда будете делать?
— А, да, сначала отверстия просверлю.
и т.д.

Петя:
— Сначала я выберу место куда его повесить, так чтобы сверху не капало и не далеко электричества. Затем приставлю его к стене и отмерю отверстия под болты. Затем возьму перфоратор со сверлом на 10 мм, просверлю отверстия и вставлю анкера. Затем одену ящик и прикручу гайки.

Как вы думаете кто выполнит задачу четко и в срок и кого возьмут на работу?
>>15 августа 2009, 00:00
Это вин! :)

Теряюсь в догадке, кто выполнит первым — из того, что человек не может объяснить вам, совсем необязательно следует то, что он сам будет «потерянным».

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

P.S. Книга есть в сети. Поищите по словосочетанию «двойной плевок пустышкой» :)
надо брать обоих, второго назначаем главным монтажником — пусть, раз так складно глаголет, руководит первым :)
Все правильно в методике работы. Именно так я и получаю «правильных» заказчиков.

Но вот оплата по часам…

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

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

В общем, перейдя на фиксированные суммы, я получаю до 30% бонусов сверху за скорость и никакого напряга с обоих сторон. Сильная мотивация для меня сделать все как можно быстрее безо всякого контроля и понятные отношения для заказчика. И возможность гибко регулировать свой график и детальный план работы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории