Рассылка закрыта
При закрытии подписчики были переданы в рассылку "Обзор инструментов SEO-оптимизатора и методов продвижения" на которую и рекомендуем вам подписаться.
Вы можете найти рассылки сходной тематики в Каталоге рассылок.
← Декабрь 2006 → | ||||||
2
|
3
|
|||||
---|---|---|---|---|---|---|
4
|
5
|
6
|
7
|
8
|
9
|
|
11
|
12
|
13
|
14
|
15
|
16
|
|
18
|
19
|
20
|
21
|
22
|
23
|
24
|
25
|
26
|
27
|
28
|
29
|
30
|
31
|
Автор
Статистика
1.618 подписчиков
0 за неделю
0 за неделю
О программистах, менеджерах и вахтерах (продолжение)
День добрый! Если вы заметили, прошлый выпуск рассылки был несколько сокращенным. Так как все эти статьи в первую очередь попадают на мой сайт, я решил сэкономить время :) и не вводить здесь всю статью полностью, ограничившись ссылкой на оригинальную версию. Однако один мой приятель вполне справедливо заметил, что если люди подписываются на рассылку, они все таки ожидают, что смогут прочесть все в письме, не выходя в интернет. Так что сорри, все тексты как и раньше будут публиковаться тут полностью (ну и естественно выкладываться на сайт ".NET: Записки программиста"). Ну а теперь вернемся к нашей теме ... О программистах, менеджерах и вахтерах (продолжение)Что еще мы можем добавить в нашу копилку "информации для размышления"? Мы участвуем в Agile-проектах. Они не могут позволить себе ту роскошь, которая составляет основу их антиподов, Formal-методологий - потратить кучу времени на тщательный анализ и планирование, перепроверить риски, проработать дизайн, опробовать технологии - и только тогда приступить к самому легкому - написанию кода. В этот момент уже все подготовлено и кодирование скорее напоминает поезд, планомерно следующий по заранее проложенному пути, вовремя останавливаясь на станциях и ровно в 22 выключая свет в вагонах, потому что пора спать. А это значит, что условия будут постоянно меняться, появляться новые пожелания и выявляться новые требования. А значит - и появляться новые риски. Ну и что?- скажете вы,- ведь Agile методологии как раз и предназначены для работы в таких условиях. Да, вот только снижение рисков и уменьшение стоимости изменений - это вовсе не нулевые риски и отсутствие этой стоимости. А кроме того, вспомните, каким образом вы получили последний проект? А предпоследний? Хорошо иметь проверенного заказчика, который оплатит вам все потраченное время и не будет искать лучшую фирму. Но, чтобы его получить, нужно с чего-то начинать. А несколько компаний будут дышать вам в затылок и в течении нескольких дней каким-то чудом предоставят архитектуру будущей системы и оценку трудозатрат. И каждая компания (в том числе и вы) понимает, что если не уложиться в эти несколько дней - то проект не получить, и времени тщательно проверять риски просто нет, а оценки затрат времени в конце концов выводяться простым "5 дней на это, 12 - на это, по 5 часов на типичные формы, по два дня на отчеты + процентов 30 на тестирование + 10 процентов буферного времени, округлим - это примерно 4 месяца, как раз максимум, который реально запросить". И чтобы удержаться, приходится перестраиваться на ходу, упрощая одни решения и задерживаясь вечером, чтобы закончить другие. А значит, к сожалению, у нас не получится упростить себе жизнь, считая, что если программист просидел с 10:00 до 19:00, то и проект беззаботно рулит к успешному завершению. Это конечно вовсе не значит, что от них потребуется постоянно засиживаться до полуночи, вовсе нет. Но без их помощи, инициативы и ответственности вы не сможете справиться со всеми задачами, и, иногда, понедельник действительно может начаться в субботу. Вспомните дни выставления новых версий или подготовка нового билда заказчику. За окном - то ли поздний вечер, то ли ранняя ночь, в углу валяются коробки из под пиццы, вы постоянно заглядываете в комнату, в которой тестируется новый релиз и вновь возвращаетесь к компьютеру - на ходу дописывая страницы кода, которые как ни странно начинают работать (про наглядность и рефакторинг пока не спрашивайте :). А теперь подумайте, что нужно, чтобы люди шли на это ради проекта? И вспомните, что говорил Джоэль о методах управления. У меня получилось вот что:
Менеджер хочет сделать проект вовремя - например он лично общается с заказчиком и ему вовсе не хочется объяснять, что тот получит ожидаемую версию с опозданием минимум на месяц. Или он понимает, что они могут упустить следующий выгодный проект. Или видит колонки цифр с недополученными доходами. Ну а, скажем, программист Алекс об этом вовсе не думает (да хотя бы потому, что вовсе не представляет себе как последствия, так и упущенные возможности). Ему интересно работать, потому что он хочет разобраться с новой библиотекой .NET AJAX Toolkit. А кто-то еще, например некий Digger, пытается побыстрее завершить проект, но исключительно из-за того, что он до смерти ему надоел. А вот скажем Ирочка, специалист по user experience, очень любит простой и понятный дизайн и поэтому проводит кучу времени, вычищая из программы различные всплывающие анимированные окна, схлопывающиеся панели и drag&drop-ные списки, широко используемые Алексом для изучения новых технологий. Так что мотивация может быть совсем разной, и то что менеджеру кажется необходимым, другому может показаться напрасной тратой времени. Хорошо, ну а почему менеджер должен смотреть на вещи с другой стороны? Ведь в конце концов это их работа - и пусть они ее делают, а понимают ли они необходимость того или иного - это их личные проблемы? И это именно то, что отличает хорошего менеджера от ... нет, вовсе не плохого, скажем - не настолько хорошего. Конечно, можно просто сказать - делайте то-то и то-то, например не забывайте отмечать время, потраченно на задачи в тот же день. И это будет правильные поступки и можно будет абсолютно правильно возмущаться, если они все таки будут забывать это сделать. А можно посмотреть на это со стороны обычного программиста, изо дня в день заносящего какие-то цифры в time-трекинговую систему и не видящего в этом ни капли пользы. И понять, что для того чтобы хотеть что-то делать - нужно хотя бы понимать, что это действительно нужно. И рассказать, что без этих цифр трудно определить прибыльность того или иного проекта. И рассчитать вместе с командой время, затраченно на разные задачи и возможно сделать какие-то выводы. И тогда, возможно, что-то чуть чуть изменится, а когда такие чуть-чуть получаются вновь и вновь - проекты удаются. И это правильно, потому что менеджеры получают свои большие деньги именно за то, что размышляют не только с позиции руководителя, но и с позиции всех остальных, за которых они отвечают. А теперь давайте задавать себе вопросы, которые (не забыли еще?) приходили нам в голову в первой части этой статьи. И перед каждым ответом задумываться, насколько это важно для успешного завершения проекта, чтобы считать необходимостью? Или не так важно, чтобы оставить это на выбор каждому? И какие разумные рамки наложить на этот выбор? Только давайте договоримся сразу, всегда найдется какой-то пример, к которому эти выводы будут неприменимы. Но мы все таки рассматриваем общую ситуацию - есть проект, длящийся несколько месяцев и главное - успешно вести его от итерации до итерации. Никаких проектов для атомных электростанций или отладки софта для марсохода Spirit в режиме реального времени :) 1. Во сколько начинать рабочий день? Зависит ли нормальная работа от того, что все разработчики будут собираться в 9 часов утра? Наверное нет. А в 10:00? Менее уверенно, но тоже нет. А если часть прийдет на 10:00, а часть - на 11? Или на 12? Вот тут начинаются оговорки. Во-первых работа одних людей часто зависит от работы других - им нужно ее координировать или просто советоваться. Но при нормальной организации, этим вовсе не обязательно заниматься с утра до вечера. Вряд ли ночью могла возникнуть проблема, из за которой я не смогу работать, пока не увижу своего коллегу. Так что вполне разумный компромисс - позволить людям самим решать, когда они прийдут на работу, но ограничить это некоторым пределом - скажем с 9 до 11 утра, чтобы быть уверенным, что в 11 часов на них можно гарантированно рассчитывать. И конечно все это с условием, что они отработают 8 часов в день. Те, кто любит вставать рано, смогут приходить на 9 и уже в 17 (на самом деле несколько позже - учитываем обед) они свободны, любишь поспать - приходи на 11 и сиди до 19 (опять таки плюс время на обед). На самом деле крайностей будет не так много, но по опыту знаю, что чуствуешь себя намного комфортнее, когда выбираешься на работу скажем к 10, но понимаешь, что при желании сможешь потратить 20 минут, чтобы заскочить в супермаркет за булочками без всяких проблем на работе.
2. Что делать, если люди будут опаздывать? Вот это уже сложнее, хотя бы потому, что платой за некоторую свободу должна быть очень четкая организация всего остального. Вот что точно не стоит использовать - так это штрафы и прочие взыскания, толку от них будет мало, а вот желание работать может здорово снизиться - хотя бы просто из чувства противоречия. Если в компании существует практика периодического пересмотра зарплат - пусть количество опозданий влияет на результат, скажем ее могут не повысить или вобще скинуть, если картина совсем грустная (это, кстати, пример из практики киевской компании Ciklum). Еще один вариант - устраивать утренние stand-up митинги1, причем не откладывать их начало, если кто-то опаздывает. Чуство, когда ты заходишь в комнату и видишь, что все уже заканчивают утреннее обсуждение - хм, достаточно неприятное и главное одно из немногих, которое почему-то способно достучаться до нашей совести. Тут главное - не перестараться и не укорять опоздавших. Если человека в чем-то обвинить - он автоматически нападет в ответ (это происходит практически подсознательно, сами же знаете, лучшая оборона - нападение) и воспитательный эффект будет утерян :)
3. Стоит ли запрещать ICQ или интернет? Давайте взвесим за и против. Минусы:
Мы больше не принимаем справок от врача. Если вы смогли дойти до врача, сможете дойти и до работы. 4. Что делать с днями, пропущенными по болезни? Скорее вопрос стоит так: нужно или нет требовать справку от врача. Опять задумаемся, зачем нам это нужно? Если в соц. пакет компании входит медицинское страхование, тогда справки нужны для получения страховки (честно говоря я слабо разбираюсь в этом вопросе, просто где-то услышал и мне показалось, что это убедительный аргумент. Так что вы мне все-таки не верьте, не проверив, хорошо? :). Только не забудьте объяснить это вашим сотрудникам, чтобы это не выглядело для них следующей причиной, а именно: Для контроля. Справка доказывает, что человек именно болел, а не решил идти на работу, скажем по причине плохого настроения. Других причин приносить справки, если нет страховки, вроде бы нет, правильно? Хорошо, запомним это как аргумент "за" и посмотрим на это со стороны сотрудников.
Возможно вы сможете добавить что-то к за и против и принять подходящее вам решение. Как вариант приведу правило, вот только хоть убей не помню из практики какой киевской фирмы (тот, кто мне это рассказывал - напомните? :) - там разрешается пропустить без справки 2 дня за месяц.
(в заключительной части статьи мы поговорим об обратной стороне медали, а так же посмотрим, выглядят ли эти размышления красивой теорией
или вполне жизнеспособны)
1 Stand-up meetings - собрания, которые проводят стоя, для того чтобы у людей не возникало желание чересчур
увлекаться разговорами.
|
В избранное | ||