&gt;Кстати, было бы интересно на очередной встрече<br>
&gt;послушать действующих руководителей на тему<br>
&gt;&quot;Как управлять разработчиками&quot;.<br><br>Я сначала воспринял это как запрос на семинар - действительно, взять Дмитрия Безуглого, или ещё какого-нибудь консультанта по управлению командами/проектами, да и провести такой доклад-обсуждение.<br>
<br>А потом подумал, что ведь всё таки - формулировка &quot;управлять разработчиками&quot; - она в себе несёт презумпцию того, что разработчик сам не может решить, что же необходимо делать. А это как-то неуважительно по меньшей мере.<br>
<br>А дальше вспомнился Agile в лице SCRUM и XP, который как раз говорит об обратном - что лучше всего, когда _команда_ разработчиков совместно принимает решение, за которое совместно несет ответственность. Притом это решение принимается совместно с _заказчиком_, через определенные здоровые процедуры обмена оценками приоритетности и трудозатрантности тех или иных фич. За приоритет отвечает заказчик, за трудозатраты - разработчики. А дальше вместе решают что оптимальней по критериям важнее/ценней-для-бизнеса/рискованней-технологически/сложнее/дольше.<br>
<br>Мне кажется, что в нашей беседе надо делать различие между работой команды и работой сообщества, тусы. Опенсорсная разработка, тусовочная разработка - это всё таки совсем не разработка под некого заказчика (в роли которого может выступать как рынок, так и отдельный человек, у которого есть видение, что нужно рынку - product owner в эджайловской терминологии).<br>
<br>Опенсорсному сообществу достаточно, чтобы были контрибьюторы, результаты которых координируются через SCM-систему. Контрибьюторы сами ставят себе задачи или договариваются между собой, исходя из того, что же им интересно.<br>
<br>Команда же должна взаимодействовать с учетом поставленных задач, и целей. Цели же определяются - заказчиком.<br><br>Мне кажется, что в случае с Глобусом у нас таки не разработка командой продукта под заказчика, а разработка сообществом чего-то интересного для себя.<br>
Основной выход-польза хакмита же была в том, что все потрогали каталист, плагер, DBI и гит, а также поработали друг с другом вместе, так ведь?<br><br>Однако теперь и вправду можно поменять точку зрения, и надеть на себя роль команды, работающей на продукт. С такой точки зрения как раз смотрит Михаил.<br>
<br>Только надо сначала каждому спросить себя, необходимо ли это, и ради чего?<br>Если да, то да, если нет - то продолжать контрибьютить по прежнему в тусовочном режиме в проект на гитхабе, и не запариваться по поводу мотивации-энтузиазма-негативногофидбека.<br>
<br>А управлять командой должна таки команда. А тусу могут воодушевлять лидеры мнений. Но ругаться как-то незачем, даже если это называть негативной обратной связью.<br><br>Спасибо за внимание, яидиотубейтеменяктонибудь.<br>
<br><div class="gmail_quote">2009/1/20 Dmitry Karasik <span dir="ltr">&lt;<a href="mailto:dmitry@karasik.eu.org">dmitry@karasik.eu.org</a>&gt;</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
 &nbsp; &nbsp; &nbsp; &nbsp;Hi Dmitry!<br>
<br>
On 20 янв 09 at 11:54, &quot;Dmitry&quot; (Dmitry Arsentiev) wrote:<br>
<br>
&nbsp;Dmitry&gt; Готовность наказывать - признак зрелости руководителя.<br>
<br>
Да, вот так будет еще точнее. Но готовность и уверенность, а<br>
не само применение наказания, т.к. эта вещь сильно<br>
демотивирующая.<br>
<br>
--<br>
Sincerely,<br>
<font color="#888888"> &nbsp; &nbsp; &nbsp; &nbsp;Dmitry Karasik<br>
</font><div><div></div><div class="Wj3C7c"><br>
--<br>
Moscow.pm mailing list<br>
<a href="mailto:moscow-pm@pm.org">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org" target="_blank">http://moscow.pm.org</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>С уважением,<br>Федин Пётр Сергеевич<br><br>тел. +7 926 335-51-30<br>mailto:<a href="mailto:pfedin@gmail.com">pfedin@gmail.com</a><br>ICQ UIN: 192054495<br>