Здравствуйте, SteMage, Вы писали:
SM>Программисты по определению не управляемы . Читайте исследования. То есть навязать программистам, что-то очень сложно.
Ты хотел сказать русские программисты?
Ими да, управлять сложнее.
То ли дело немец. Ему сказал "делай так", он и будет "делать так"
А вообще, на мой взгляд, это больше миф, что программисты менее управляемы.
Тупо приказывать действительно сложнее,
а в целом больших проблем не вижу.
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, minorlogic, Вы писали:
M>>Скажу крамолу. M>>Управлять группой из 10 человек — физически невозможно. M>>Максимум 3-5 (5 — потолок)
B>Ну если подобрать неуправляемых, B>да поручить это дело начинаещему начальнику, B>то он и с одним не справится
Могу сказать , что я говорю об эфективной работе, конечно не так много руководителей заинтересованны в этом.
А пример могу посоветовать брать с организации комуникаций в сетевом маркетинге (в успешных примерах).
Да и вообще поискать инфу про работу малыми группами.
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, minorlogic, Вы писали:
M>>Могу сказать , что я говорю об эфективной работе, конечно не так много руководителей заинтересованны в этом.
B>Я может быть и поверил тебе, B>если бы не работал в маленькой команде (12 голов ), B>которая вполне нормально управляется одним руководителем.
Здравствуйте, webinc, Вы писали:
W>Здравствуйте, minorlogic, Вы писали:
M>>Это не означает что он плохой руководитель, возможно просто дали руководить группой из 6 человек, а это физически невозможно, ну и плюс он не разделил этих 6 человек на 2 группы и т.д.
W>Почему невозможно управлять группой из 6 ти человек?
Еще раз повторяю , можно создавать фикцию управления, хоть с 1000 человек. Достаточно объективным критерием тут можно использовать вот что :
Если руководитель не знает что делает в данную минуту каждый член его команды , он группой не руководит.
Здравствуйте, minorlogic, Вы писали:
M>Еще раз повторяю , можно создавать фикцию управления, хоть с 1000 человек. Достаточно объективным критерием тут можно использовать вот что : M>Если руководитель не знает что делает в данную минуту каждый член его команды , он группой не руководит.
Ты лучше книжку напиши: "Новое в менеджменте от Michael Norel"
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, SteMage, Вы писали:
SM>>Программисты по определению не управляемы . Читайте исследования. То есть навязать программистам, что-то очень сложно.
B>Ты хотел сказать русские программисты? B>Ими да, управлять сложнее. B>То ли дело немец. Ему сказал "делай так", он и будет "делать так"
B>А вообще, на мой взгляд, это больше миф, что программисты менее управляемы. B>Тупо приказывать действительно сложнее, B>а в целом больших проблем не вижу.
Я именно о тупо приказывать и говорил. А раз тупо приказывать нельзя, то приходится тратить время на коммуникации. То есть приходится объяснять, что зачем, почему из-за чего. На это уходит время. Да еще нужно убедится, что программист действительно согласился, а не сказал да-да и сделал по своему. А то знаете. У меня случай был, начальство очень хотело, чтобы я сделал интерфейс пользователя именно таким, как они хотели. Я взял и повесил на параметр, как должен выглядеть интерфейс пользователю. То есть начальство видело интерфейс пользователя таким как оно хотело и я таким каким его хотел .
Вообще-то это не миф. Но это не значит, что программисты не управляемы. Просто тупо навязать им что-то очень трудно. Вы это даже сами подтвердили. Как результат приходится тратить больше времени на коммуникации. Составлять дополнительные документы, проверять код и т.д.
Да кстати у вас начальник делает Code Review? Если нет то видимо он не управляет тем что происходит. То есть если совсем отдать техническую часть, то вполне возможно, что можно и 12 управлять.
Здравствуйте, SteMage, Вы писали:
SM>Вообще-то это не миф. Но это не значит, что программисты не управляемы. Просто тупо навязать им что-то очень трудно.
Ага, именно по этой причине в любой более менее серьезной
модели качества требуется чтобы все заинтересованные лица (не толко девелоперы)
поняли и приняли взятые на себя обязательства.
Это касается всего, от планов, до тестов...
Те из начальников, для которых это в обузу,
будут себя гораздо комфортнее чувствовать в армии
SM>Да кстати у вас начальник делает Code Review? Если нет то видимо он не управляет тем что происходит. То есть если совсем отдать техническую часть, то вполне возможно, что можно и 12 управлять.
Начальник не должен лично проводить code review.
Я бы даже сказал, что это очень плохая практика,
когда непосредственный начальник в этом принимает участие.
Его задача спланировать это мероприятие
и убедиться что оно прошло и проблемы, найденные на review
никуда не пропали и не забылись.
Должны проводиться так называемые peer review среди разработчиков,
которые не зависят друг от друга по иерархической лестнице.
Это, на мой взгляд, очень принципиально.
Основная задача начальника — руководить.
А это в первую очередь — планирование, контроль и координация.
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, minorlogic, Вы писали:
M>>Если руководитель не знает что делает в данную минуту каждый член его команды , он группой не руководит.
B>Хм... B>То, что о чем ты говоришь — это не эффективное управление, B>а тотальный контроль. Нафиг нафиг такие методы .
B>Если не пытаться следить за всем и всеми, B>то управление 10-ю девелоперами вещь вполне реалистичная.
B>Ну а если управление — это когда без тебя и шагу ступить нельзя, B>то тогда ты и с одним не управишься.
Я имею ввиду "управление == координация" а не "управление == контроль".
Попробуйте вспомнить наиболее продуктивные моменты своей лучшей командной работы , скорее всего работа велась малой группой.
Здравствуйте, bralgin, Вы писали:
B>Здравствуйте, minorlogic, Вы писали:
M>>Еще раз повторяю , можно создавать фикцию управления, хоть с 1000 человек. Достаточно объективным критерием тут можно использовать вот что : M>>Если руководитель не знает что делает в данную минуту каждый член его команды , он группой не руководит.
B>Ты лучше книжку напиши: "Новое в менеджменте от Michael Norel"
Ты ошибаешься , если думаешь , что это я сам придумал.
Эх, не люблю я вступать в полемику, но все же отвечу
SIE>И в какой книжке вы его прочитали?
Книжек я чилал много разных — шкаф на работе и дома забит, так что список был бы очень большим.
А тот процесс, что у нас есть, это компиляция популярных методик и исторических реалий.
SIE>И с чего вы взяли что они всё не выдумывают? Они бы с удовольствием говорили правду, если они вкалывают "по полной", но программирование — не перетаскивание кирпичей и трудно оценить какую часть кучи ты сегодня перетащил, а те кто халявят, тянут время — те и просто врут...
Отвечу и на это — врать им резона нет никакого. И возможности тоже нет никакой — все люди сидят в одной очень большой комнате,
так что я всегда вижу и знаю кто чем занимается. Кроме того, я очень хорошо знаю каждого из них, знаю их индивидуальные особенности,
и знаю что сложившийся внутри коллектива климат не наводит их на мысли о вранье.
На самом деле мне уже не первый раз задают этот вопрос и я не первый раз ему удивляюсь — у меня в текущем коллективе, которым
я руковожу более 2-х лет ни разу не было такой проблемы. Ни одного раза. Это часть нашей внутренней культуры.
SIE>Виртуальный.
Нет не виртульный, а очень даже реальный. Я всегда вижу, что происходит с проектом — где мы отстаем, а где забегаем.
M_E>>1. Составлять все более точные планы, так как со временем точность прогноза членов команды повышается. SIE>А если сразу набрать профессиональных программистов то они более-менее точно будут оценивать объём работы.
Да, но вы же понимаете, что мы берем не только профессиональных программистов. Например, берем выпускников ВУЗов — обычно они
слишком оптимистичный оценки трудозатрат. Или людей, которые работали в ИТ-подразделениях, где планирование не требовалось.
SIE>И гордиться этим безумно! Пионерия какая-то...
Я вовсе не безумен (справки у меня, правда, нет ).
Вы видимо не вполне понимаете зачем требуется отчетность для руководства компании.
Она требуется для принятия решений и для отслеживание текущего состояния дел в проекте —
какие требования каких клиентов и когда будут выполнены, успеем мы выпустить новую версию к очередной выставке или нет и т.п.
SIE>Всё так же плохо?
да вроде ничего
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, SteMage, Вы писали:
B>Те из начальников, для которых это в обузу, B>будут себя гораздо комфортнее чувствовать в армии
А еще комфортней он будет себя чуствовать в женском коллективе. А самая некомфортная среда для таких начальников это среда технических специалистов. А на объяснение приказов надо время.
B>Основная задача начальника — руководить. B>А это в первую очередь — планирование, контроль и координация.
То есть собственно технической частью он совсем не занимается. Кстати с высокой долей вероятности часть управленческой работы проделывает ответственный за архитектуры. Тогда вполне реально.
Насколько я понял речь шла о Team Lead'ах. Так я думаю, что в такой ситуации 12 человек мало реально. ИМХО.
Здравствуйте, minorlogic, Вы писали:
M>>>Если руководитель не знает что делает в данную минуту каждый член его команды , он группой не руководит.
B>>Ты лучше книжку напиши: "Новое в менеджменте от Michael Norel"
M>Ты ошибаешься , если думаешь , что это я сам придумал.
Здравствуйте, Michael_E_Smrinov, Вы писали:
M_E>Отвечу и на это — врать им резона нет никакого. И возможности тоже нет никакой — все люди сидят в одной очень большой комнате, M_E>так что я всегда вижу и знаю кто чем занимается. Кроме того, я очень хорошо знаю каждого из них, знаю их индивидуальные особенности, M_E>и знаю что сложившийся внутри коллектива климат не наводит их на мысли о вранье. M_E>На самом деле мне уже не первый раз задают этот вопрос и я не первый раз ему удивляюсь — у меня в текущем коллективе, которым M_E>я руковожу более 2-х лет ни разу не было такой проблемы. Ни одного раза. Это часть нашей внутренней культуры.
А можно имя компании, чтобы знать, что продукты данной комапнии нельзя покупать, поскольку их цена явно не соответствует качеству.
1. Большое количество багов раз все сидят в одной комнате. Не верите поинтересуйтесь, как работают корректоры. Работа программистов во многом на эту работу похоже. Поэтому одна большая комната тождественна много багов.
2. Исходя из того что сказано скорее всего большая проблема с повышением квалификации, скорее всего люди ощущают дискомфорт, что то же приводит к увеличению багов.
Я прекрасно понимаю зачем и что нужно начальству. Вот только большинство из начальства не совсем понимает стоимость отчетности. То есть стоимость отчетности при разного рода процессах может быть в несколько раз выше стоимости разработки продукта и приводить к понижению качества конечного продукта. Вот этого почему то многие руководители не хотят видеть. И не хотят объективно оценивать стоимость такой отчетности. И соответственно с потребностями бизнеса или клиента выстраивать процесс разработки.
P.S. Да на всякий случай я не говорю, что управлять не надо и надо все пустить на самотек.
А можно имя компании, чтобы знать, что продукты данной комапнии нельзя покупать, поскольку их цена явно не соответствует качеству.
Имя компании ничего вам на скажем, а кроме того ее продукты отсутствуют в свободной продаже —
мы работаем для постоянных клиентов на длительных проектах.
SM>1. Большое количество багов раз все сидят в одной комнате. Не верите поинтересуйтесь, как работают корректоры. Работа программистов во многом на эту работу похоже. Поэтому одна большая комната тождественна много багов.
Действительно, при большом кол-ве разработчиков в одной комнате такая проблема может быть, но 10 человек в достаточно
большой комнате такую проблему не создают.
Я нахожусь здесь на месте и мне здесь лучше видна атмосфера внутри коллектива, нежели со стороны.
SM>2. Исходя из того что сказано скорее всего большая проблема с повышением квалификации, скорее всего люди ощущают дискомфорт, что то же приводит к увеличению багов.
По поводу этого — проблема состоит из двух частей —
1. сложности с повышением квалификации у тех, кто не стремится ее повышать.
2. (более серъезная) в нашем городе почти все разработчики либо занимаются 1С, либо уже работают у нас, либо уехали в Москву; так что предложение о том, чтобы сразу нанять профессионалов неприменимо.
Здравствуйте, Ed.Nixon, Вы писали:
EN>В небольшой команде программистов (<10 человек) уже используется таск менеджмент система, позволяющая просто ставить задачки, асайнить их и т.п. (аля багзила). Однако хочется повысить уровень самоконтроля. Есть идея ввести следующую процедуру: EN>Каждый составляет свой план работ на месяц и неделю и каждую неделю записывает что он сделал за эту неделю, информацию можно для простоты хранить в wiki. Кроме того каждый будет видеть что делали другие, что является мотивирующим фактором.
А почему бы не добавить сколько всего/сколько осталось к задачам в упоминавшейся системе?
План (на неделю, месяу, год) можно разбить на задачи и поприсваивать народу...
Здравствуйте, Michael_E_Smrinov, Вы писали:
SIE>>И с чего вы взяли что они всё не выдумывают? Они бы с удовольствием говорили правду, если они вкалывают "по полной", но программирование — не перетаскивание кирпичей и трудно оценить какую часть кучи ты сегодня перетащил, а те кто халявят, тянут время — те и просто врут...
M_E>Отвечу и на это — врать им резона нет никакого. И возможности тоже нет никакой — все люди сидят в одной очень большой комнате, M_E>так что я всегда вижу и знаю кто чем занимается. Кроме того, я очень хорошо знаю каждого из них, знаю их индивидуальные особенности, M_E>и знаю что сложившийся внутри коллектива климат не наводит их на мысли о вранье. M_E>На самом деле мне уже не первый раз задают этот вопрос и я не первый раз ему удивляюсь — у меня в текущем коллективе, которым M_E>я руковожу более 2-х лет ни разу не было такой проблемы. Ни одного раза. Это часть нашей внутренней культуры.
Смущает один момент.
Согласен с вашим утверждением относительно того, что, врать в отчетах — дело бессмысленное и довольно рискованное, но не согласен с его обоснванием.
Вы, фактически, утверждаете, что получаете дотоверные сведения от разработчиков, исключительно за счет хороших личных отношений, длительной совместной работы, етк.
По сути, это утверждение свидетельствует о сырости вашего процесса. Идеальный (и недостижимый) процесс должен исключать влияние человеческого фактора и человеческих отношений на качество и производительность работ. Хороший процесс — это процесс нечувствительный (ну или как минимум малочувствительный) к смене членов проектной комманды. В вашем же случае — наоборот, основа процесса — это личные отношения. Стало быть, если завтра на ваше место придет новый руководитель, вероятность провала проекта резко повысится...
Я не говорю о том, что пипл-фактор должен игнорироваться менеджментом. Безусловно, это важнейший элемент в управлении интеллектуальным трудом. Однако вектор продждект менеджмента (особенно в крупных проектах) должен быть направлен формализацию отношений и процессов.
SIE>>Виртуальный. M_E>Нет не виртульный, а очень даже реальный. Я всегда вижу, что происходит с проектом — где мы отстаем, а где забегаем.
Опять же — вы. Основываясь на личном опыте и сложившейся системе отношений в коллективе.
На вашем месте я бы ввел чуть больше формализма в процесс мониторинга текущего состояния работ.
Для этого есть ряд техник:
— это планирование не только времени но и ОБЪЕМА работ (строки кода, функциональные объекты) — это позволит получить, чистую, лишенную субъективизма метрику текущего статуса путем банального вычисления текущего объема от запланированногож
— это ежедневные билды с репортами о добавленной функциональности и результатми юнит тестирования этой функциональности
— это небольшие итерации разработки, с демкой в конце каждой итерации
— еще много чего — при желании можем обсудить подробнее...
Большое спасибо!
Отвечаю по пунктам.
S>По сути, это утверждение свидетельствует о сырости вашего процесса. Идеальный (и недостижимый) процесс должен исключать влияние человеческого фактора и человеческих отношений на качество и производительность работ. Хороший процесс — это процесс нечувствительный (ну или как минимум малочувствительный) к смене членов проектной комманды. В вашем же случае — наоборот, основа процесса — это личные отношения. Стало быть, если завтра на ваше место придет новый руководитель, вероятность провала проекта резко повысится...
Согласен, процесс еще далек от идеала. Многое из того, что мне бы хотелось внедрить, пока внедрить не получается.
Причин тому несколько (я уже писал как-то об этом ранее). Основные из них:
1. Очень тяжело внедряются изменения в процесс, если для них нет весомых предпосылок.
Согласен, что предпосылки нужно предвидеть и действовать заранее, что я и делаю, но некоторые вещи
(например, внедрить RequisitePro) сделать пока не получается.
2. Давно работающие люди, которые со скрипом привыкают к изменениям в их обычной работе.
Они думают, что им стали меньше доверять, иногда что за ними хотят следить и т.п.
S>Я не говорю о том, что пипл-фактор должен игнорироваться менеджментом. Безусловно, это важнейший элемент в управлении интеллектуальным трудом. Однако вектор продждект менеджмента (особенно в крупных проектах) должен быть направлен формализацию отношений и процессов.
Совершенно с вами согласен. По мере расширения проекта необходимость повышения формализации очевидна.
Стараюсь двигаться в эту сторону.
Опять же, повторюсь, пока не все удается, но сделано уже многое.
S>На вашем месте я бы ввел чуть больше формализма в процесс мониторинга текущего состояния работ.
Можете привести пример?
S>Для этого есть ряд техник: S>- это планирование не только времени но и ОБЪЕМА работ (строки кода, функциональные объекты) — это позволит получить, чистую, лишенную субъективизма метрику текущего статуса путем банального вычисления текущего объема от запланированногож
На счет оценки строк кода — мне это кажется довольно спорным — например, тестировщики и администраторы вообще не пишут код.
Или даже разработчики — они могут писать по строке в день, а на следующий день написать 1000 строк, но ведь это не значит что предыдущий день они не работали. Мне пока как-то более привычно оперировать трудозатратами выраженными в человеко-часах.
S>- это ежедневные билды с репортами о добавленной функциональности и результатми юнит тестирования этой функциональности
Ну это я уже давно внедрил — году два назад
Каждый день просходит сборка системы и выгрузка на тестовые сервера.
Затем тестировщики полностью проверяют все систему (в том числе с использованием автоматических средств)
Найденные ошибки заносятся в базу ошибок и направляются разработчикам.
Разработчики исправляют ошибки и помечают их как выолненные.
При последующем разверывании системы на тестовые сервера тестировщики верифицируют эти ошибки и либо закрывают, либо возвращают на доработку.
Разверывание на рабочие сервера происходит примерно раз в неделю при отсутствии серъезных проблем.
S>- это небольшие итерации разработки, с демкой в конце каждой итерации
Ну вот примерно так и получается — накопившыеся запросы от клиентов я стараюсь планировать примерно на 3 недели чистого времени.
Дальше я считаю, что разработчики работают примерно 6 часов чистого времени в день.
Изходя из этого, план рассчитывается на 4 недели, в конце которых мы имеем окончание очередной итерации.
Конечно, длительности итерации могут меняться. Кроме того, поскольку системы уже стала довольно большой, то
1. Границы между итерациями становяться все менее четкими.
2. Разные части системы начинают развиваться в обособленных итерациях.
S>- еще много чего — при желании можем обсудить подробнее...
Согласен обсудить и что потребуется применить.
В нашем городе я не знаю никого, с кем бы я мог посоветоваться по данным вопросам.
. Читайте исследования. То есть навязать программистам, что-то очень сложно. 
