[Moscow.pm] Globus. Vision.

Peter Fedin pfedin на gmail.com
Вт Янв 20 03:39:04 PST 2009


>Кстати, было бы интересно на очередной встрече
>послушать действующих руководителей на тему
>"Как управлять разработчиками".

Я сначала воспринял это как запрос на семинар - действительно, взять Дмитрия
Безуглого, или ещё какого-нибудь консультанта по управлению
командами/проектами, да и провести такой доклад-обсуждение.

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

А дальше вспомнился Agile в лице SCRUM и XP, который как раз говорит об
обратном - что лучше всего, когда _команда_ разработчиков совместно
принимает решение, за которое совместно несет ответственность. Притом это
решение принимается совместно с _заказчиком_, через определенные здоровые
процедуры обмена оценками приоритетности и трудозатрантности тех или иных
фич. За приоритет отвечает заказчик, за трудозатраты - разработчики. А
дальше вместе решают что оптимальней по критериям
важнее/ценней-для-бизнеса/рискованней-технологически/сложнее/дольше.

Мне кажется, что в нашей беседе надо делать различие между работой команды и
работой сообщества, тусы. Опенсорсная разработка, тусовочная разработка -
это всё таки совсем не разработка под некого заказчика (в роли которого
может выступать как рынок, так и отдельный человек, у которого есть видение,
что нужно рынку - product owner в эджайловской терминологии).

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

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

Мне кажется, что в случае с Глобусом у нас таки не разработка командой
продукта под заказчика, а разработка сообществом чего-то интересного для
себя.
Основной выход-польза хакмита же была в том, что все потрогали каталист,
плагер, DBI и гит, а также поработали друг с другом вместе, так ведь?

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

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

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

Спасибо за внимание, яидиотубейтеменяктонибудь.

2009/1/20 Dmitry Karasik <dmitry на karasik.eu.org>

>        Hi Dmitry!
>
> On 20 янв 09 at 11:54, "Dmitry" (Dmitry Arsentiev) wrote:
>
>  Dmitry> Готовность наказывать - признак зрелости руководителя.
>
> Да, вот так будет еще точнее. Но готовность и уверенность, а
> не само применение наказания, т.к. эта вещь сильно
> демотивирующая.
>
> --
> Sincerely,
>         Dmitry Karasik
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
С уважением,
Федин Пётр Сергеевич

тел. +7 926 335-51-30
mailto:pfedin на gmail.com
ICQ UIN: 192054495
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20090120/6b87efc6/attachment-0001.html>


Подробная информация о списке рассылки Moscow-pm