Comments 25
До этой фразы (выделение мое):
считал, что это собственноручно написанная статья, а унылый «перевод для привлечения хоть какого-то внимания к компании» (
Они с усердием пытаются измерять хоть что-нибудь — ведут учет ежедневно написанного количества линий кода или свежеотлаженных багов,
считал, что это собственноручно написанная статья, а унылый «перевод для привлечения хоть какого-то внимания к компании» (
Спасибо за замечание, поправила.
UFO just landed and posted this here
Ну вот в том и вопрос, что 1) иногда кажется, что администрации ресурса на контент будто бы наплевать, 2) правила не требуют компиляции как-то помечать, и 3) корп. блогах можно писать вообще любой текст (а потом ссылаться на него, мол, «на Хабре-то писали, что...»), неважно, относится ли это к правде вообще каким-то боком.
Декларированные механизмы «саморегуляции» Хабра в этих случаях не помогают: стоит написать провокационную чушь, и мы имеем не массу минусов (которые корп. блогам не страшны), а рост комментов. Вывод прост: нормальный контент не даст пиара, надо писать дерзко, с вызовом, и получишь свое внимание публики.
Хотя нет, что это я? Администрация недавно упоминала, что Хабр переводят авторы западных сайтов, так что все в порядке, значит, качество всего контента — на «мировом уровне» :)
Декларированные механизмы «саморегуляции» Хабра в этих случаях не помогают: стоит написать провокационную чушь, и мы имеем не массу минусов (которые корп. блогам не страшны), а рост комментов. Вывод прост: нормальный контент не даст пиара, надо писать дерзко, с вызовом, и получишь свое внимание публики.
Хотя нет, что это я? Администрация недавно упоминала, что Хабр переводят авторы западных сайтов, так что все в порядке, значит, качество всего контента — на «мировом уровне» :)
Эффективность «эффективных манагеров» постоянно упираются в з-н Эшби:
Разнообразие управляющей системы должно быть не меньше разнообразия управляемого объекта. На практике это означает, что чем сложнее объект управления, тем сложнее должен быть и орган, который им управляетТ.е. управленец хорошего разработчика должен быть более продвинутым разработчиком. И кто же будет убивать курицу несущую золотые яйца? Т.е. переводить разработчика в управленцы? Конечно, это возможно на фабриках разработки ПО, в крупных интеграторах. А как быть в небольших коллективах? В итоге, в управленцы попадают не самые лучшие разработчики. А еще чаще люди «гуманитарного склада ума», т.е. особи с дефицитом логического мышления. И это проблема.
Вы неправильно интерпретируете закон. Он говорит не о том, что начальство должно быть более компетентно в профессии рядового работника, чем рядовой работник.
ИМХО вообще нечего делать программистам в руководстве.
Руководство должно быть умным и адеватным. Программистские знания им не нужны. Должны быть доверенные технические спецы, которые будут не давать разработчикам обманывать с технической стороны. И в свою очередь не позволяет руководству допускать грубые ошибки в техническом плане. И всё.
Само руководство программистами быть не должно.
Руководство должно быть умным и адеватным. Программистские знания им не нужны. Должны быть доверенные технические спецы, которые будут не давать разработчикам обманывать с технической стороны. И в свою очередь не позволяет руководству допускать грубые ошибки в техническом плане. И всё.
Само руководство программистами быть не должно.
В армии отлично бы смотрелось — «офицеры не должны быть военными, пусть будут одни доверенные солдаты, которые не дадут другим недоверенным солдатам обмануть балбесов-командиров». Просто блеск
Бредовая метафора.
Но ок. Давайте от нее отталкиваться.
Важно ли, чтобы генерал знал как чистить винтовку и из неё стрелять? Я вот думаю что не важно.
Часто генералу вообще не приходится мыслить категориями винтовок.
Каждый руководитель должен знать какие инструменты есть у его подчиненных и какие задачи можно этим инструментом решать.
НА уровне солдата надо хорошо владеть винтовкой и знать её.
На уровне сержанта — знание винтовки это хорошо. Но уже начинает играть знание людей отделения. Потому что важнее знания винтовки знаение, кто из отделения лучше стреляет, то лучше бегает и кто лучше ползает, кто подвержен панике и т.п.
А вот начиная с капитана важность знаний о винтовках начинают расплываться. И чем дальше — тем больше.
Капитан уже должен ориентироваться в частях своей роты. И о винтовках он долежн знать, что они есть и исправны. И всё.
Генерал-майор — ему вообще на эти винтовки чихать. Ему надо понимать, как части его дивизии действуют в тех или иных обстоятельствах и как надо действовать тактически и стратегически.
Ах да. ПОчему я ваш аргумент про армию считаю бредовым? Да потому что очень большая часть высших командиров оружие в руках никогда не держало(кроме как на учебных стрельбах) и солдатами не были, начиная сразу с офицеров после подготовки в военных ВУЗах. Вы выбрали дико неудачную метафору, потому что она как раз опровергает то, что вы сами сказать хотели.
Но ок. Давайте от нее отталкиваться.
Важно ли, чтобы генерал знал как чистить винтовку и из неё стрелять? Я вот думаю что не важно.
Часто генералу вообще не приходится мыслить категориями винтовок.
Каждый руководитель должен знать какие инструменты есть у его подчиненных и какие задачи можно этим инструментом решать.
НА уровне солдата надо хорошо владеть винтовкой и знать её.
На уровне сержанта — знание винтовки это хорошо. Но уже начинает играть знание людей отделения. Потому что важнее знания винтовки знаение, кто из отделения лучше стреляет, то лучше бегает и кто лучше ползает, кто подвержен панике и т.п.
А вот начиная с капитана важность знаний о винтовках начинают расплываться. И чем дальше — тем больше.
Капитан уже должен ориентироваться в частях своей роты. И о винтовках он долежн знать, что они есть и исправны. И всё.
Генерал-майор — ему вообще на эти винтовки чихать. Ему надо понимать, как части его дивизии действуют в тех или иных обстоятельствах и как надо действовать тактически и стратегически.
Ах да. ПОчему я ваш аргумент про армию считаю бредовым? Да потому что очень большая часть высших командиров оружие в руках никогда не держало(кроме как на учебных стрельбах) и солдатами не были, начиная сразу с офицеров после подготовки в военных ВУЗах. Вы выбрали дико неудачную метафору, потому что она как раз опровергает то, что вы сами сказать хотели.
P.S>
Еще парочка выдающихся моментов из армейской метафоры.
Верховный главнокомандующий вполне может быть человеком не то чтобы солдатом не бывшим, а вообще гражданским лицом.
Да что там верховный главнокомандующий.
История России знает Генерала-Армии, который был гражданским.
Еще парочка выдающихся моментов из армейской метафоры.
Верховный главнокомандующий вполне может быть человеком не то чтобы солдатом не бывшим, а вообще гражданским лицом.
Да что там верховный главнокомандующий.
История России знает Генерала-Армии, который был гражданским.
На сцене появилась история и гражданские генералы? Это уже было, директора колхозов, рулящие дивизиями и не знавшие с какой стороны пуля из ствола вылетает. Правда потом супостат купался в Крыму, стоял на Волге и катался в Сокольниках на мотоциклах.
Ладно, я не любитель пустых споров, творческих успехов вам.
Ладно, я не любитель пустых споров, творческих успехов вам.
Забыли про самое главное. Больше всего продуктивность разработчиков убивают попытки управления разработкой и планирования задач. Попытка планировать разработку всегда очень быстро вырождается в ситуацию, когда разработчики сознательно преувеличивают время, необходимое на ту или иную задачу, чтобы всё-таки выполнить задачу в срок, даже если возникнут непредвиденные сложности. А затем начинает работать известный закон: «Работа всегда занимает столько времени, сколько на неё выделено.» Из пяти дней, выделенных на работу, которую можно выполнить за один день, один день будет потрачен на работу, а четыре оставшихся дня — это padding.
И как, по-вашему, выходить из этой ситуации? Не планировать разработку?
Не планировать нельзя. Но можно планировать так, чтобы сами разработчики не знали этих планов. От разработчиков требуется лишь дать первичную оценку сроков. А какие сроки после этого попадут в реальный план, им знать не нужно. И менеджер должен сам накапливать статистику по тому, насколько реальное время выполнения задач отличается от заявленного разработчиками. Исходя из этой статистики, для каждого разработчика можно рассчитать коэффициент пересчёта его собственной оценки сроков в то время, которое действительно следует выделить на задачу. Ключевой момент в том, что сами разработчики не должны знать этого реального срока, от соответствия которому зависит выполнение плана. В противном случае они подсознательно будут стремиться максимально совпасть с планами. Либо будут спешить и лепить костыли даже там, где можно было сделать нормально. Либо будут растягивать до неприличия, зная, что время ещё есть.
Главное, чтобы не получалось ситуации, когда ответ разработчиков «запрошенное клиентом в принципе невозможно» превращается в «мы будем счастливы нарисовать семь взаимно перпендикулярных зеленых линий красного цвета за неделю». Менеджмент при этом исходит из того, что разработчики не хотят браться за сложные, нудные задачи, но по факту способны их сделать хоть как-то. Клиент просит, а что он просит — не все не-разработчики понимают. И вот здесь дилемма: либо руководитель проекта разбирается в технической стороне дела, но тогда он будет не в фаворе у своего руководства (возьмется «отвлекаться на мелочи» и часто говорить клиент «нет»), либо разбирается только в общении с клиентами (читаем — «ни в чем не разбирается», как с точки зрения завязанных на него технических специалистов), но постоянно выглядит молодцом у своего рук-ва. Методом естественного отбора получаем то, что получаем )
На самом деле, хорошее руководство очень любит, когда разработчики вовремя предупреждают его о том, что необходимо сказать клиенту «нет». Совершенно не разбираясь в чисто технических вопросах, оно обычно кое-что знает об управлении рисками. В противном случае вообще непонятно, что такое руководство делает на своём месте. А с точки зрения рисков самый страшный кейс — это когда клиенту уже пообещали, сказав «да», а на деле сделать обещанное никак не получается.
"Нельзя управлять тем, что нельзя измерить — так звучит одна из излюбленных аксиом гильдии менеджеров."
Всегда привожу по этому случаю закон Гудхарта как контраргумент:
"Закон (принцип) Гудхарта заключается в том, что когда социальный или экономический показатель (KPI) становится целью для проведения социальной или экономической политики, он перестаёт быть достойным доверия показателем."
В общем статья о том, что надо вводить Agile или ещё какую-либо «модную» методологию отработанную на заводах или швейных фабриках и превратить образованного программиста в раба, который будет отчитываться о лишних 10 минутах проведённых в туалете…
А зря, ведь в туалете часто появляются гениальные идеи.
Тогда кроме отчета по «туалетным» минутам нужно еще кратенький отчетик на три страницы за идеи, приходящие в туалетной комнате.
Через полгода будем иметь статистику самых «идейной» кабинок. Там видится апгрейд остальных, для приведения процента идейности к нужному уровню, указание столовой готовить «правильную» для посещения «идейного» места пищу, и план по числу туалетных идей.
Ух, это ж какое направление! «Аж дух захватывает!» )))
Через полгода будем иметь статистику самых «идейной» кабинок. Там видится апгрейд остальных, для приведения процента идейности к нужному уровню, указание столовой готовить «правильную» для посещения «идейного» места пищу, и план по числу туалетных идей.
Ух, это ж какое направление! «Аж дух захватывает!» )))
Производительность падает от слишком многих субъективных и объективных факторов ))
Но, по опыту, есть удобный для работодателя и исполнителя, при этом не самый трудный путь к повышению КПД коллектива. Я о менеджменте знаний (Knowledge management) и спец. ПО для его постановки на предприятии специализирующемся на разработке.
Но, по опыту, есть удобный для работодателя и исполнителя, при этом не самый трудный путь к повышению КПД коллектива. Я о менеджменте знаний (Knowledge management) и спец. ПО для его постановки на предприятии специализирующемся на разработке.
На самом деле есть один(и, к сожалению, единственный) замечательный способ увеличения производительности — мотивировать разработичка. Мотивированный разрабочтик будет показывать высокую производительность и качественный результат.
Как мотивировать? Да я представления не имею. Еще ни одного годного совета на эту тему не видел. Деньги точно не работают… Другие мотиваторы результата тоже не показывают…
Как мотивировать? Да я представления не имею. Еще ни одного годного совета на эту тему не видел. Деньги точно не работают… Другие мотиваторы результата тоже не показывают…
Безотносительно к содержанию (хотя проблема, затронутая в статье, вполне годная для обсуждения)
Есть в статье три слова: Программист, разработчик, программер. Последнее на каком языке? Правильное слово на русском длиннее всего на одну букву.
Извините если кого обидел, но это уже достало. Зачем использовать разговорные словечки в серьезной статье. Это ведь могут увидеть дети, а потом из них вырастают эффективные менеджеры которые носят дОговоры в пОртфеле.
Есть в статье три слова: Программист, разработчик, программер. Последнее на каком языке? Правильное слово на русском длиннее всего на одну букву.
Извините если кого обидел, но это уже достало. Зачем использовать разговорные словечки в серьезной статье. Это ведь могут увидеть дети, а потом из них вырастают эффективные менеджеры которые носят дОговоры в пОртфеле.
Sign up to leave a comment.
О том, что убивает продуктивность разработчиков