Курс выживания менеджера программистов
8 апреля 2009 в 19:55

Курс выживания менеджера программистов

Курс выживания менеджера программистов или 29 основных ошибок, который совершают программисты, становясь руководителями»
© Александр Орлов
С-Петербург, 2007 

PS Публикуется с любезного согласия автора — Александра Орлова,
члена нашей группы

Представляется, есть что обсудить.

870
Комментарии (27)
  • 8 апреля 2009 в 19:56 • #
    Игорь Цесельский

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

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

    Во-вторых, во многих книжках по менеджменту даются модели сферического менеджера в вакууме. Вообще большинство книг – оно про методологии, управление задачами, рисками, изменениями и чем угодно, но не людьми. А жизнь она гораздо красочней. Что делать, если ваш ведущий разработчик приходит к вам с просьбой поднять зарплату, а то он уйдет к конкурентам? Как быть к этому готовым и как это все предвидеть и предотвращать?

    В-третьих, те материалы, которые есть про управление людьми, они часто не ориентированы именно на программистов. А это очень, очень необычные люди. Технические и творческие одновременно.

    Наконец, вы вдруг обнаруживаете, что кроме ваших сотрудников есть еще ваш начальник и коллеги менеджеры. Со своими амбициями, желаниями и пониманием, что такое хорошо и что такое плохо. Как с этим жить, тоже пока не очень понятно. А в книжках про это тоже пишут не очень…

    Все это накладывается одно на другое и получается как. На работе случаются продвижения и сокращения. Первые обходят вас стороной, а вторые наоборот незаметно подкрадываются сзади. Как выжить в такое нервной обстановке?

  • 11 апреля 2009 в 14:41 • #
    Борис Вольфман

    Игорь!
    Имею особое мнение к некоторым Вашим утверждениям:
    Отсутствие материалов по управлению программистами: Брукс, Йордан, Салливан, предлагаю их не забывать
    Наличие высокопрофессиональной литературы и ее изучение не достаточно для необычных, технических и одновременно творческих людей, чтобы они перешли из статуса профессиональных программистов в профессиональные менеджеры.
    Не считаю эффективным перечислять 29 основных ошибок, достаточно дать две установки молодым руководителям из программистов:
    Изучите основы менеджмента, в том числе ИТ-менеджмента;
    Забудьте, что у Вас программисткое прошлое.

  • 12 апреля 2009 в 21:11 • #
    Игорь Цесельский

    Борис, прочтите топик темы.
    На предмет вашего особого мнения - к чьим утверждениям)

  • 12 апреля 2009 в 22:15 • #
    Борис Вольфман

    Игорь, возможно я и запутался:

    чьи это утверждения: "Если вы уже успели немного поруководить программистами, будучи менеджером, тим-тех лидом небольшой команды...."

    Ваши или автора курса "Курс выживания менеджера программистов" Александра Орлова.

    Уточняю обращение к Александру Орлову:

    Рекомендую в "Курсе выживания менеджера программистов" перечисление 29 и более ошибок заменить алгоритмом:

    1. Изучить основы менеджмента, в том числе и программных разработок (PMI, RUP, MSF, ГОСТ34, CMMI ...
    2. Забыть о своем прошлом программиста.
    3. Читать классиков: Брукса, Йордана, А.Орлова....

    Успехов Вам, А.Орлову и другим менеджерам из бывших программистов..

  • 8 апреля 2009 в 19:57 • #
    Игорь Цесельский

    Команда

    Ошибка №1. Нанимают людей глупее себя. Происходит это обычно из-за простого самолюбия. Когда начальнику очень тяжело смириться с тем, что кто-то в его команде будет умнее. Кто-то в его команде, вы только подумайте, будет программировать лучше него! Этак он найдет код, написанный начальником, и – о боже! Он же его разнесет в пух и прах!

    К чему это приводит – очевидно. Все сложные задачи начальнику придется решать самостоятельно. Задач будет все больше и больше, времени – все меньше и меньше.

    Ошибка №2. Просят рекомендации на человека до собеседования. Есть такая статистика, что только 5-10% людей нанимают через объявления. Все остальные приходят на собеседования по знакомству. И действительно. По знакомству нанимать как-то понадежней будет.

    Но есть одна ошибка, которую совершают многие – они запрашивают рекомендации на человека _до_ собеседования. Рекомендации от знакомых обычно хорошие. В итоге, в голове заранее складывается картинка, что вы этого человека хотите нанять. И что бы он не говорил потом на интервью, его ошибки воспринимаются как-то снисходительно, а правильные ответы наоборот подтверждают установку.

    В итоге, человека нанимаете, а он оказывается, не такой классный.

    Ошибка №3. Полагаются на симпатию. Во время собеседований некоторые менеджеры смотрят, насколько им симпатичен собеседуемый как человек. Если симпатичен, то нанимают. Ну, потому что, если человек симпатишный, то он, скорее всего, неконфликтный. То есть в команду впишется нормально. А знания – дело наживное. И нанимают. В итоге, потом часто получают симпатичного человека, но слабого инженера. Со всеми вытекающими.

    Ошибка №4. Проводят собеседование в одиночку. Менеджеры иногда любят проводить собеседование самостоятельно. Или с менеджерами других команд. Но почему-то не приглашают своих сотрудников. Тем самым, подчеркивая, кто тут принимает решения. Или я уж не знаю, что этим подчеркивают. Но явно что-то ненужное. Следствием является то, что потом возникают проблемы с адаптацией человека в коллективе. Потому что, даже если вам лично он симпатичен, нет никакой гарантии, что команда его примет.

    Ошибка №5. Не просят написать код. В жизни такое встречал очень часто. Когда человеку задают много теоретических вопросов, или даже практических, но код написать не просят. Это очень смешно. Примерно, как нанимать жонглера в цирк, но не попросить его пожонглировать.

    Ошибка №6. Оценивают только текущие знания человека. Иногда на собеседовании задают очень много вопросов на текущие знания. Причем, часто спрашивают то, что можно за пять секунд найти в хелпе или Гугле. Типа: перечислите наизусть все методы класса java.util.MegaClass. Оправдание очевидное – «нам нужно, чтобы человек сел и сразу начал работать». Однако, программирование – такая область, где знания очень быстро устаревают. Текущие знания станут бесполезными через два года.

    Если человек новыми знаниями не может быстро овладевать, то будет непросто.

  • 8 апреля 2009 в 19:57 • #
    Игорь Цесельский

    Люди в команде
    Ошибка №7. Методологии – это все. Часто встречающееся заблуждение task-oriented менеджеров, это то, что если следовать вот именно этой методологии, то все будет хорошо.

    Проблемы начинаются сразу при попытке методологию внедрить. Будет публичное неприятие, потом якобы согласие и саботаж, много чего интересного будет… Но фокус в том, что ни одна методология не застрахует вас от, скажем, семейных проблем у программистов. Или того, что другая компания начнет агрессивно нанимать людей. А времени на то, чтобы подстраховать незаменимых людей, отдокументировать весь код, справиться со всеми рисками, не будет ни-ког-да.

    Решают не методологии, а люди.

    Ошибка №8. Неправильное использование метрик. Люди творческие, к которым программисты относятся, вне всякого сомнения, очень не любят, когда их измеряют. Потому что считают, что их творчество и полет мысли нельзя измерить.

    Однако, многие менеджеры все равно пытаются людей сравнивать. По количеству написанных строк кода, количеству дефектов на тысячу строк кода и многим другим интересным метрикам, на изучении которых ученые пишут диссертации, а консультанты зарабатывают много денег.

    В итоге, часто менеджеры начинают поощрять тех людей, у которых в смысле метрик все хорошо, и не поощрять тех, у кого плохо. Главный момент состоит в том, что исправить метрику – очень легко. Что нужно сделать, чтобы строк кода было побольше? Почаще использовать copy-paste. Поменьше функций, побольше кода в функциях на десять экранов! В итоге по метрикам все становится хорошо, но если заглянуть внутрь, то – ужас, ужас…

    Причем, заметим, что метрика не всегда однозначна. Если взять какой-нибудь продукт, например «Сапера» стандартного. Один инженер написал его в 1 тыс. строк кода. Другой в 20 тыс. строк кода. Кто молодец?

    Очевидно, что первый. Потому что второй наверняка не знает что такое циклы, функции, какие есть библиотеки и пр.

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

    В общем, непонятно. Надо разбираться. Метрика – это сигнал, что надо разобраться. Не более того.

    Ошибка №9. Бюрократия. Любят ли творческие люди бюрократию? Не надо быть семи пядей во лбу, чтобы ответить на этот вопрос. Однако, многие менеджеры любят отчеты. Поподробней, почаще. Понятно, что в отчетах иногда есть необходимость. Но еще чаще необходимости именно в том, чтобы присылать отчеты именно такой формы и раз в два часа – нет.

    В одном из проектов мы, помнится, заполняли отчеты строк на 70 со списком заданий и по часам – кто что сколько делал. Потом наводилась статистика, сколько у нас уходило на то, на се. Были ли люди счастливы от таких отчетов? Нет. Тратили ли они на заполнение отчета много времени. Да, тратили. Нужна ли была кому-то эта статистика? Практически, нет.. Достаточно было собрать данные за месяц. А не писать эти отчеты полгода.

    Ошибка №10. Поощряется процесс, а не результат. Очень многие менеджеры любят установленный процесс. Процесс – это гораздо лучше, чем хаос. Но тут есть одна тонкость.

    Любя процесс, они поощряют всеми силами его использование. Совершенно забывая про цель процесса – обеспечивать результаты. Считается, что если следовать процессу, то результат будет. А это не всегда так. Иногда для результатов нужно немного творчества и немного хаоса.

    Люди – они очень адаптивные. Поощряется процесс, а не результаты? Будет процесс, не будет результатов.

    А заказчик, заметим, платит в итоге за результат, а не за процесс.

    Ошибка №11. Одновременно несколько задач. Мы все с детства знаем верный способ не поймать ни одного зайца. И почему-то очень часто пытаемся повторить эксперимент на работе. Со своими сотрудниками.

    Человеку дается два задания, которые он должен делать одновременно. Или четыре задания, так еще надежней.

    Чтобы эффективно начать делать задание человеку нужно время на «включение». Если делать их одновр

  • 8 апреля 2009 в 19:58 • #
    Игорь Цесельский

    Начальство
    Ошибку №18. Не управляют своим начальником. Очень многие менеджеры занимают исключительно пассивную позицию по отношению к начальству. В чем это выражается?

    «Нам говорят – мы делаем». Почему-то мало кто хочет сам придумывать себе, что делать. Большинство уверены, что это задача начальства говорить, что делать.

    Второй симптом – уверенность, что мнение начальство изменить нельзя. Причем, настолько нельзя, что некоторые даже не пытаются. (Заметим, что изменять мнение – это не обязательно вступать в открытую конфронтацию.)

    Все остальные ошибки относительно начальства, по большому счету являются следствием этой.

    Ошибка №19. Не говорят начальству «Нет». То есть воспринимают слова своего менеджера как приказ к исполнению. Тем более, что, сказать «нет» означает поставить под сомнение авторитет самого! Что интересно, что чем больше начальник, тем обычно более адекватно он воспринимает мысли и возражения подчиненных. По крайней мере, мой опыт общения с большими менеджерами подтверждает это на все сто.

    Еще одна причина невозражений в том, что часто менеджерами становятся достаточно бесконфликтные люди (мой случай). Которым психологически проще согласиться. Но тут они рано или поздно совершают:

    Ошибку №20. Боятся донести до начальства плохие новости. Потому что, один раз не сказав «Нет», подписываются под нереальными сроками. После чего дела становятся все хуже и хуже. А доносить эту новость до начальства все страшнее и страшнее. И так по замкнутому кругу. Пока не происходит большой упс.

    Слабые менеджеры пытаются выйти из ситуации, совершив:

    Ошибку №21. Пытаются свалить вину на команду. Это может прокатить, только если вашим начальником является полный идиот или абсолютно беспринципный человек.

    В противном случае, вам укажут, что за результат отвечаете вы. И где вы были все это время, пока жизнь настойчиво указывала вам на приближение неотвратимого финала?

    Плюс, один раз свалив вину на команду, можно смело из нее уходить. Отношения с людьми уже не наладятся.

    Второй по популярности попыткой выйти из безвыходной ситуации с нереальными сроками является:

    Ошибка №22. Критика начальства. Это когда вы сваливаете вину на начальство. И вместе с командой переживаете, какое же оно, начальство, тупое.

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

  • 8 апреля 2009 в 19:59 • #
    Игорь Цесельский

    Вы сами
    Ошибка №23. Переработки. Некоторые люди почему-то думают, что много работать это очень хорошо. Если менеджер не перерабатывает, то он плохой менеджер. Это очень странная точка зрения. Потому что карьера не идет вверх от количества работы. Она идет вверх от ее качества.

    Переработки плохи очень многим.

    В первую очередь страдает семья и личная жизнь. Просто потому что на них остается меньше времени.

    Есть такое мнение, что у каждого человека обязательно в жизни должно быть три вещи: работа, семья и хобби. Если у человека все это есть, то все у него хорошо и гармонично развивается. Как только что-то одно начинает пожирать время за счет другого – счастья не жди.

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

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

    Самое неприятное в переработках – это чувство что ты все равно ничего не успеваешь. И в итоге становишься раздражительным, срываешься на близких людях, на своих же сотрудниках. Они демотивируются, уходят или перестают работать, и дальше все по замкнутому кругу.

    Следующие несколько ошибок как раз являются причинами переработок.

    Ошибка №24. Замыкание информационных потоков. Что это значит? Это значит, что менеджеры не делятся какой-то информацией, предпочитая быть ее единоличным обладателем. Опять же, по себе знаю, что это очень приятно обладать каким-то знанием, которым мало кто обладает. Потом можно при случае его выгодно выложить. Это приятно, как-то собственная важность повышается, но это отнимает очень много времени. Потому что без вас ничего решиться не может.

    Типичная ситуация. Вы уходите в отпуск на две недели. Оставляете формального заместителя. И он на любой вопрос говорит: ну, я тут принять решение не могу, давайте Сашу подождем. Вы возвращаетесь из отпуска. И тут на вас наваливаются текущие дела и то, что накопилось за две недели.

    Ошибка №25. Микроменеджмент. Микроменеджмент – это, на самом деле, такая форма недоверия человеку. Вы дали ему какое-то задание. Но не доверяете ему его выполнение. Поэтому вмешиваетесь как можно чаще и говорите ему, какие именно кнопки нажимать. Тут несколько негативных факторов:

    Во-первых, это отнимает массу времени.

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

    В-третьих, вы так всю жизнь потом и будете все это сами делать. Потому что, человек уже не будет брать на себя ответственность за то, что вы сами делаете.

    Еще одной ошибкой, связанной с недоверием, является:

    Ошибка №26. Отсутствие делегирования. Вы были хорошим программистом. Потом стали менеджером. И вот прилетает техническая задача, которую вы можете сделать за два дня. А можете делегировать ее сотруднику и он ее сделает за неделю, при этом три дня будет вас спрашивать, как и что делать.

    Конечно, делаете сами. В итоге, сотрудники не учатся, и потом вы делаете сами все время (см. «Переработки»).

    Частным случаем этой ошибки является желание самому сделать работу интересной.

    Ощибка №27. Сами пытаются сделать работу интересной. Программирование – это не всегда новые технологии, интересные алгоритмы и творческие задачи. Естественно, у менеджера возникает желание ее разнообразить, чтобы люди сразу не разбегались.

    Сотрудникам это нравится. Но что плохо – что они начинают считать, что это задача менеджера – делать работу интересной. А, на самом деле, это задача каждого сотрудника делать ее интересной. “There is no boring job, there are boring people” ((c) Jim McCarthy).

    Ошибка №28. Переделегирование. Но вот вы уже продвинутый менеджер и знаете, что задачи надо делегировать. И раздаете их направо и налево.

    Может с

  • 8 апреля 2009 в 21:07 • #
    Владимир Шелухин

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

  • 9 апреля 2009 в 00:10 • #
    Игорь Цесельский

    Владимир, я постарался разделить текст на логически законченные части, которые можно обсуждать и комментировать раздельно.
    Он, собственно тут и размещен, чтобы оспорить и развить, в противном случае достаточно было бы ссылки.
    Хотя, автор высылает свои заметки по почте частями после рагистрации.

  • 9 апреля 2009 в 00:20 • #
    Владимир Шелухин

    Да вы и отлично всё разделили. Всё же для обсуждения в форуме, imho, слишком монументально.

  • 8 апреля 2009 в 21:06 • #
    Елена Замирович

    Игорь, основная ошибка в том, что будучи программистом - человек выполняет одни функции, а став менеджером - использует те же подходы в решении принципиально иных задач. Нельзя программистам дать менеджера - непрограммиста, они его вынесут вперед ногами, наденут на голову веночек и поставят возле двери. Возможно вверх ногами. Ну не любят они тех, кто не понимает в их святом деле. Но и выходцу из своей среду способны "кузькину мать" показать по полной программе. Поэтому возможно более толкового в поведенческом плане человека нужно еще и специально обучить. Обязательно. Иначе перечисленные Вами ошибки превратятся в замкнутый круг. Менеджер учится и исправляет, но и команда программистов то же учится, и снова вынуждает его делать ошибки, он ведь просто не будет готов к изменению ситуации. Видела! Поверьте, это не смешно!

  • 8 апреля 2009 в 23:59 • #
    Игорь Цесельский

    Елена, не я автор) Вернитесь в топик темы.
    Кое с чем - согласен, кое-что представляется иначе.
    В частности - с положением "Нельзя программистам дать менеджера - непрограммиста" категорически не согласен.
    Основное положение - что программисты (кстати, сейчас это понятие далеко не однозначно - кодеры? тестеры? архитекторы? и тп) - явление уникальное - ложно, кстати, здесь по старинке многие IT-специалисты так себя и ведут.
    Эти времена давно и безвозвратно прошли, и чем раньше люди это поймут - тем лучше для них.
    Это совсем не так. Сейчас основная масса (95%) - это станочники и пекари IT-технологий, ничего особенного и прекрасно взаимозаменяемы, так же как и инженеры-проектировщики и тп.
    Разумеется, управлять ими, да и никем вообще, не сможет тот управляющий, который "позволит себя вынести вперед ногами, надеть на голову веночек и поставить возле двери".
    Он вообще не управляющий.
    А вот до какой степени он должен разбираться в технологиях софтостроения можно обсуждать, так же как здесь обсуждают, должен ли IT-директор понимать в IT-технологиях или PM быть специалистом по профилю проекта.
    На мой взгляд - совершенно бесполезные обсуждения., ибо компетентность в субъекте управления - важная составляющего успеха.
    Это не очивидно. многих выпускников очень серьезных и очень дорогих учебных заведений на протяжении всей учебы убеждают в том. что полученных общих управленческих знаний им будет достаточно. чтобы сразу стать универсальным руководителем. Это печально заканчивается для всех тех, кто в это поверил.

  • Цена: $2,000,000

  • 9 апреля 2009 в 00:19 • #
    Елена Замирович

    Я видела, что не автор. С Вашими доводами нельзя не согласиться и спорить я не собираюсь. К сожалению, многим менеджмент видится как средство универсальное, позволяющее не вникать в особенности ТЕХНОЛОГИИ деятельности. В итоге наплодили менеджеров, которые понятия не имеют о специфике объекта своей деятельности. Потом говорится, что у нас переизбыток. Как был дефицит, так и остался. Увы...

  • 9 апреля 2009 в 02:56 • #
    Игорь Цесельский

    Безусловно. Вообще, вы Елена упомянули ключевое слово современной цивилизации - Технология. Давно пришел к этому выводу, считал и считаю, что многие беды как СССР так и современной РФ проистекают от пренебрежительного отношения именно к технологиям. Весь почет и сливки всегда у нас доставались идеологам, генераторам идей, организаторам-мы-за-ценой-не-постоим (впрочем, к которым и я себя отношу), но как только дело упиралось в качественную реализацию - выяснялось, что нет нормальных специалистов-технологов (это же второй сорт!), способных довести продукт до нужной кондиции в производстве с заданными параметрами (в том числе экономическими).
    Отсюда культ Левши, слесаря Васи, который пальцами микроны ловит, уникальные продукты в одном экземпляре для выставки, тонны нереализованных изобретений, уникальная СВЧ-печь с вращающимся полем стоимостью в Жигули и пр и пр. Впрочем, Стругацкие об этом лучше написали...

  • 9 апреля 2009 в 19:34 • #
    Елена Замирович

    Согласна абсолютно. Любое действие или совокупность действий, можно довольно легуо представить в виде цепочки опреаций. Но только при одном условии: в результате должно получиться нечто, обозначаемое целью и хорошо описанное. Если
    это го не сделать, получается бесконечный и безрезультатный процесс.

  • 9 апреля 2009 в 00:33 • #
    Борис Вольфман

    Игорь!
    Два основных принципа должны быть обеспечены при управлении коллективом разработчиков профессионального ПО:

    Единственный враг - СЛОЖНОСТЬ

    Единственный критерий - Работает ПО или не работает.

    Все остальное следствие: документируемость, тестируемость, масштабируемость, интригуемость, и т.п.
    Не претендую на открытие Америки.

    Еще принцип, должен быть обеспечен:

    ДВОЕВЛАСТИЕ -

    В коллективе разработчиков должно быть два начальника:

    Функциональный руководитель: отвечает за ресурсы и ПРОЦЕССЫ - профи.
    Руководитель проекта: планы, сроки, бюджет, риски,

    В проектной бригаде два начальника:

    руководитель проекта;
    технический лидер - отвечает за технические риски, оба за проект.

    У аналитика два начальника: Заказчик (требования должны его удовлетворять) и архитектор (требования д.б. реализуемы)
    и т.д.

    Начальство не административное.

    По поводу менеджера: вопрос спорный, должен он разбираться в программировании (PMI не советует), но делегировать или не делегировать разработку архитектуры? Требовать устойчивость архитектуры обязан.

    Но если программист пошел в менеджеры и не изучил принципы менеджмента, психологии, не знает методику освоенного объема, не руководствуется правилами General Electric, то он достиг уровня некомпетенции по закону Мэрфи.

    Перечисленные Вами (Орловым) ОШИБКИ носят в основном фоновый характер, противоречат разделению ответственности в коллективе разработчиков: например: пусть интригуют, плюют друг на друга и топают ногами - это менее критично, чем СГОВОР программиста с тестировщиком (второму будет неудобно отмечать ошибки первого - к чему это приведет сами знаете.).
    Пусть ябедничают друг на друга, доносят и т.п., но мудрый руководитель по этой информации будет больше знать о состоянии разработки и обязан их натравливать друг на друга: с ошибками ушло ПО Заказчику - виноват тестер, не ушло Заказчику из-за выявленных на этапе тестирования ошибок - программист виновен.

    На самом деле, по каждой ОШИБКЕ можно дискуссию разводить: дискового пространства на сервере не хватит.
    Предлагаю поэтому обсуждать проблемы, как и разрабатывать сложное ПО, разбивать на простые вопросы.

    ГЛАВНЫЕ ПРОБЛЕМЫ и ПРОТИВОРЕЧИЯ между бизнес-менеджерами и разработчиками, между Заказчиками и Исполнителями и т.п.
    Различные знания, компетенции, понимание (вернее - непонимание друг друга) СЛЕПОЙ с ГЛУХИМ.

    Забыл еще один принцип - ЧУВСТВО ЮМОРА.

    Всего доброго.
    Спасибо за хорошую тему.
    Начал писать книгу по данной теме: название придумал, содержание в черновике есть:

    "Как научить программиста учиться на чужих ошибках"

  • 15 апреля 2009 в 16:08 • #
    Алексей Тигарев

    >Перечисленные Вами (Орловым) ОШИБКИ носят в основном фоновый характер, противоречат разделению ответственности в коллективе разработчиков: например: пусть интригуют, плюют друг на друга и топают ногами - это менее критично, чем СГОВОР программиста с тестировщиком (второму будет неудобно отмечать ошибки первого - к чему это приведет сами знаете.).
    >Пусть ябедничают друг на друга, доносят и т.п., но мудрый руководитель по этой информации будет больше знать о состоянии разработки и обязан их натравливать друг на друга: с ошибками ушло ПО Заказчику - виноват тестер, не ушло Заказчику из-за выявленных на этапе тестирования ошибок - программист виновен.
    ===============

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

    Если подобное поведение специально провоцируется руководителем, то слаженной работы никогда не будет, и вскоре в команде останутся только те, кто компетентны в подковерных интригах, а не в своей специальности.

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

    Если для обоих имеет какое-то значение успех проекта, то сотрудничество будет продуктивным: программист будет благодарен тестировщику за его часть работы. Вот мотивацией команды на общий успех и должен заниматься руководитель, а не "разделяй и властвуй".
    Принцип "разделяй и властвуй" нужен для поддержания власти над сообществом с насильным членством (напр. государство) а не для людей, добровольно устроившихся на работу в компанию и получающих за свою работу деньги. Сообщество, созданное на добровольных началах, может быть значительно эффективнее, чем согнанная в одно место группа рабов. Не стоит превращать первое во второе.

  • 16 апреля 2009 в 00:13 • #
    Борис Вольфман

    Алексей!
    Обращаю Ваше внимание на один важнейший принцип в непростом деле "Создание программного продукта" - ЧУВСТВО ЮМОРА.
    А теперь по полочкам: именно принцип разделения ответственности позволяет говорить о команде разработчиков, футболистов, разведчиков, теннисистов.
    А если руководитель не разграничит ответственность между аналитиком и архитектором, то будет ПИН-ПОНГ -
    аналитик будет учить архитектора как строить архитектуру,
    а архитектор модернизировать требования, чтобы проще было реализовывать.
    Да руководитель обязан ПРОВОЦИРОВАТЬ требовательность между членами команды, именно тогда будет слаженная работа и никак иначе и останутся только профессионалы, а уйдут интриганты, не способные сами выполнить работу и адекватно воспринять требовательность партнера.

    Сговор программиста и тестировщика проблема не надуманная, а естественная. Вместе работают, уважают друг друга - как следствие - требовательность к результатам друг друга сглаживается, это недопустимо: должна быть профессиональная "спортивная" ЗЛОСТЬ. Тестер в очередной раз проверяя ПО должен в голове внушать себе: я докажу этому программеру, что программ без ошибок не бывает, а программер разрабатывая код должен мыслить - не дождешься тестер - не будет у меня ошибок, как бы ты не старался.
    Прошу читая инструкцию не забывать о принципе, сформулированном в начале.
    И принцип "Разделяй и Влавствуй" для руководителя обязательно должен быть, но с уточненной формулировкой:
    Разделяй ответственность и влавствуй над принятием решений ОТВЕЧАЙ за общий результат.
    Понятие добровольно устроившихся на работу я не понимаю. А с термином группа рабов согласен, действительно разработка ПО "рабский" труд, но рабовладельцем его является СЛОЖНОСТЬ разработки.
    И программист выбрав рабскую специальность должен понимать, что его работа не заканчивается разработкой красивого алгоритма и устранением синтаксических ошибок - нужно потратить еще 95% времени на то, чтобы все альтернативные потоки работали, выходные формы - ровные, интерфейсы без грамматических ошибок и т.д.
    Всего доброго.

  • 9 апреля 2009 в 00:42 • #
    Александр Лебедев

    Я уже полгода числюсь руководителем отдела программистов. В программировании в первые месяцы был абсолютным дубом, но, месяц за месяцем, по чуть-чуть втянулся. Немого разбираюсь в ПХП, немного в ЦМСках, иногда подключаю логику. + достаточно неплохо получаются административные обязанности - повышение бюджетов работ, отчёты и т.п.
    Сжились, приняли за своего, не жалуюсь) Единственное - кризис немного придавил, но общими силами перерабатываем сайт и продумываем новые концепции, думаю - выкарабкаемся.

  • 9 апреля 2009 в 09:10 • #
    Борис Вольфман

    Александр! Вас приняли за своего, потому-что Вы не мешаете программистам принимать технические решения и взяли на себя административные обязанности. Не заблуждайтесь в том, что начали разбираться в ПХП и ЦМС. Научиться программировать, как и плавать можно только на практике. А это время в ущерб административной работе. Лучше сосредоточиться на организации процессов, в первую очередь на требованиях, качестве, рисках. А кризис Вам должен помочь сплотиться: не до интриг, подсиживания, разработки безрезультативных проектов и т.п.

  • 9 апреля 2009 в 10:42 • #
    Александр Лебедев

    В некотрых ЦМС я разбираюсь лучше своих же программистов ибо добрался до них раньше и опыт построения сайтов на базе open-source ЦМС был и раньше. Относительно ПХП - только общую логику построения программ, не более)

    П.С. Никто не мешает мне добывать дополнительные знания на досуге, не в ущерб работе. Обычно, я так делаю. Мне это интересно и приносит пользу - по крайней мере теперь я могу указывать на недоработки чётко аргументируя и поясняя ошибку программеров.

  • 9 апреля 2009 в 11:13 • #
    Борис Вольфман

    Александр! Добыча новых знаний безусловно приветствуется, но в Вашем случае я бы рекомендовал включить в процесс тестировщика, пусть тот указывает на недоработки, а более правильно: на несоответствие результатов работы программера техническому заданию, содержащему требования Заказчика.

    Вы совместили в одном лице две роли: тестировщика и Директора. В малых коллективах это не запрещается.

    ЦМС Вы скорее всего изучили с позиции функций и возможностей и это верно, но внутреннюю реализацию СМS программеры обязаны понимать лучше, они за это деньги получают.
    Ваша обязанность: не позволять программерам изобретать велосипед, не выделять на проекты ресурсов, если они могут быть обеспечены штатными средствами open source продуктов.

  • 9 апреля 2009 в 15:20 • #
    Александр Лебедев

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

    Тестировкой проектов занимаются программеры которые работали над другими проектами, то бишь, идёт "перехлёст".

  • 9 апреля 2009 в 15:32 • #
    Борис Вольфман

    ОК!
    Я бы ненавязчиво рекомендовал в рамках развития подразделения выделить отдельных тестеров. Программист и тестер - роли не совместимые.
    А Директор, менеджер и тестер - совместимые в малых коллективах.
    У программиста даже с другого проекта, свои проекты в голове, а тестер должен не пропустить ошибок - ИНЖЕНЕР по КАЧЕСТВУ - своя зона ответственности.

  • 9 апреля 2009 в 15:36 • #
    Александр Лебедев

    ) Думаю, если переберёмся через кризис, обязательно воспользуюсь вашим советом )

  • 16 апреля 2009 в 20:14 • #
    Аркадий Куров

    Читал это раньше, я подписан на рассылку Александра, многие вещи кажутся интересными, хоть и не бесспорными.


Выберите из списка
2018
2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008