Что может помочь менеджеру проектов в работе с программистами

    Предыдущая статья была достаточно популярна. Я обещал продолжить и держу слово. Делюсь своим личным мнением и не претендую на истину.

    В этой части пойдет речь про работу с программистами.



    1. Вместо костылей нужен фундамент. Люди, а не методологии


    Из опыта внедрений различных методологий Agile сделал следующие выводы
    1. Вполне понятным кажущимся решением многим кажется использование типовых советов. Вера в серебряную пулю, джинна из бутылки свойственно большинству людей, менеджеры проектов — не исключение.

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

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

    4. Как ответ разработчиков на все это, появились знаменитый английский манифест «Programming, Motherfucker! Do you speak it?» и его русский вариант.

    5. В конечном счете, вода камень точит. Не буду утверждать, что методологиями в стиле «потратим час на [censored] болтовню» программистов достали, но какая-то доля влияния здесь есть. Наиболее рутинные куски в разработке стандартизовали и автоматизировали — и все чаще стали появляться прекрасные статьи от Яндекса, Badoo и так далее, как выстроен процесс разработки. Где большое внимание уделено техническим инструментам, которые реально роляют на процесс разработки, в отличие от бесконечных плясок с бубном.

    Хочу отметить, что с программистами, которые умны и хотят работать, достаточно легко взаимодействовать. Вы объясняете человеку, зачем нужен функционал, и обсуждаете user stories. Какие-то архитектурные моменты. И дальше человек реализует то, что нужно, точно и красиво.

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

    Кадры решают все, об этом сто раз писали, но грабли до сих пор свеженькие и отполированные новыми лбами.

    2. Управление требованиями и входными данными как эффективное средство упрощения задач


    Хочется сразу отметить, что я не верю в теоретические знания. Можно прочитать сто книжек и сдать на PMI, MBA и множество других слов, но заваливать все проекты. А можно и делать проекты, как пирожки, не владея ценными «знаниями».

    Речь пойдет о навыке, которые развивается в процессе практики. Хочу привести лишь пару примеров, чтобы было понятно, в каком направлении мыслить и какой эффект это может дать.

    Кейс 1. Делается рассылка e-mail писем, ссылка в которых ведет на лэндинг. Встает задача у молодого менеджера проектов, ограничить от спама форму на лэндинге.
    Берется пример у другой рабочей группы, как сделать такую защиту на 8+ часов.
    И тут приходит более опытный человек, и предлагает внимательно изучить начальные условия. Лэндинг предназначен только для открытия из почтовых писем.
    Следовательно, в первой версии достаточно в ссылках из писем ставить некий ключ в URL, который будет вызывать показ формы на лэндинге. А при прямом заходе форму не показывать.

    Придумать — одна минута, делать — 15 минут. Против 8+ часов. Без комментариев.

    Кейс 2. Обращается ко мне менеджер проектов. Нужно, мол провести опрос на проекте. Был какой-то движок опросов, можно ли его прикрутить, или писать свой.
    Последовательно задаются вопросы
    — Сколько раз нужно проводить опрос? Ответ: один раз
    — Будут ли меняться поля: Ответ: нет, не будут.
    — Сколько участвует в опросе пользователей. Ответ: десяток.

    Через минуту выдаю решение — сделать форму на Гугл Докс, и поставить на проекте ссылку. Реализация — минуты, против дней на прикрутку движка опросов, отладку, вынос на релиз и так далее.

    Сюда же относится и занос контента статикой (HTML), если он не меняется чаще раза в месяц, вместо создания движка и WYSIWYG, и много других вещей.

    Овладев уточнением исходных условием и держа мысль в голове «как это можно сделать проще и быстрее», вы можете значительно ускорить разработку. И научить этому своих программистов.

    3. Раскрытие личностного потенциала вместо шаблонного общения


    Программисты, как и любые другие творческие личности, уникальны. Ведь не стали бы вы общаться с Азимовым в роли издателя так, как общались бы с Толстым. А с Пушкиным тоже бы вели свой диалог.

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

    Начинается все с шаблонных вопросов на собеседовании про «кем вы видите себя в компании через 5 лет», и может продолжаться весь срок работы человека в компании.

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

    Например, у меня работает талантливый программист, в прошлом дизайнер и верстальщик. Достаточно уникальный опыт, и поэтому с ним в процессе общения и постановки задач можно не беспокоиться, что он сделает некрасиво. И задачи я подбираю такие, которые наиболее точно позволят ему раскрыться. Мне кажется, это его мотивирует — и неспроста он уже развивает целые проекты в моем отделе.

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

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

    Каждый программист имеет свои способности, свое прошлое, и индивидуальный подход, по моему мнение — то, что может повысить вашу продуктивность работы с командой в разы. Гораздо лучше, чем всех согнать в один опен-спейс, чтобы люди чаще болели и мешали друг другу шумом, несмотря на то, что это рекомендуют разные «дипломированные ребята». Демарко писал об этом 20 лет назад и до сих пор актуален.

    4. Не идите за всеми — это нередко кончается провалом


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

    Как ни странно, это правило работает и в управлении проектами. Чем больше будет вокруг суеты, в топиках — стадного чувства, тем меньше советую идти на поводу у инстинктов.

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

    Увы, есть простая аналогия, которая говорит, что ресурсов почти всегда меньше, чем их потенциальных потребителей, и имеет место конкуренция.
    Вот стоит палатка с молоком, и в день ходит 100 человек. Палатка успешна, и появляются конкуренты 2,3,4,...N. А как ходило 100 человек, так и ходит. Но прибыль каждой уменьшается с появлением новых, и в конечном итоге разоряются все (один из вариантов сценария).

    Вот и так происходит с новыми нишами в бизнесе (вспомните те же купонаторы).

    Есть и другой пример, где данная рекомендация работает чуть иначе.
    Вчера все сидят на NoSQL, сегодня пилят на jQuery, завтра SVG+HTML5, послезавтра 3d для FaceculusRift.

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

    В противоположность один известный сайт бронирования отелей, работающий на [censored] мамонтов Perl. Я на Perl не писал уже лет 10, и все жду легендарного Перла 6. Офигенный был язык (и остается). Насколько я знаю, ежики колются, плюются, но продолжают жрать кактус. И проект растет и развивается, не страдая от резкий падений «а потом мы переписали все на Джаве (подставьте ваш язык) и купили еще 1000 серверов, чтобы не падало каждый час».

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

    Вот говорят, на дизайне исправить ошибку в 1000 раз дешевле, чем на продакшене. А в мышлении — в infinity раз. Только мало кто задумывается об этом, судя по неудачным стартапам повсюду.

    5. Научитесь программировать


    Вот говорят, что рыбак рыбака узнает издалека. Даже если вы ничего не прочитали и просто прокрутили вниз, вы уже получите пользу.
    Если вы научитесь программировать, то обойдете сотни тысяч молодых парней и девушек, кто мечтает о высокой зарплате в IT, но хотят только управлять.
    Ибо своих любят и признают в любой среде, а если руководитель программиста технически подкован, то это дает +1000 (ИМХО) к скиллу уважения.

    Но, по исследованиям, к авторитетам лучше прислушиваются.

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



    В комментариях предлагаю поделиться вашими находками из опыта, какими-то кейсами, которые считаете интересными.
    Share post

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 16

      –2
      мамонтов Perl… Насколько я знаю, ежики колются, плюются, но продолжают жрать кактус.

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

        Там не самые глупые люди сидят, чтобы так вешать ярлыки на них. Видимо это оправдано бизнесом, раз продолжают пилить. Например поэтому фейсбук не переписал все на C++, а вместо этого сделал другой PHP движок.
          +1
          В Facebook как раз целый зоопарк технологий. Если у вас куча legacy-кода, то ничто не мешает писать новые сервисы на чем угодно и интегрировать их в legacy. SOA для этого и придумали. Упорствовать в использовании 1го устаревшего языка для меня свидетельство того, что кто-то крепко сидит на своем стуле и не хочет его отпускать.
          +1
          Они просто нанимают людей с опытом любого скриптового языка, и переучивают. Видимо, это проще, чем переписывать тонну легаси кода.
          +8
          Немного сумбурно, чувствуется как гигантский опыт по капле сочится через решето блогоформата.
            +5
            Что может помочь менеджеру проектов в работе с программистами

            Быть самому в прошлом программистом.
              +1
              Согласен, причём это относится не только к программистам.

              Какие бы навыки управления не были, всё же важно разбираться в объектной части.
              Иначе без этого будут или неточные постановки задач, или же разделение мнений.
              0
              Как по мне, то как-то совсем печально вышло: знаешь методологии — не факт, что ты менеджер; умеешь программировать — хорошо, но тоже вроде как недостаточно; умеешь программировать и знаешь методологии — и это не панацея от провалов. А описанный индивидуальный подход работает только если на проекте не слишком много народа, имхо.
                +2
                С менеджерами которые были в прошлом программистами, есть опасность. После перехода в менеджеры они могут продолжать сильно участвовать в технической части проекта. Хотя по сути должны уже делегировать эту часть тимлиду и команде. Не у всех получается задавить свое «я» бывшего программиста и признать что теперь команда умнее.
                  +1
                  Как-то слышал, что был древнегреческий философ, ходил днём с огнём и искал Человека. Похоже, актуально до сих пор. Так-то понятно, что в малой команде индивидуальная совместимость и персональные качества играют большую, чем всё остальное, роль. Ну и по поводу персональной мотивации вкусными задачами — всё так, но вкусных задач мало, а рутины всегда больше (и её тем больше, чем профессиональнее команда).
                    +1
                    Диоген это был, по-моему
                    +4
                    <сарказм>
                    Открыть сарказм
                    image

                    </сарказм>
                      +1
                      Вот говорят, на дизайне исправить ошибку в 1000 раз дешевле, чем на продакшене. А в мышлении — в infinity раз. Только мало кто задумывается об этом, судя по неудачным стартапам повсюду
                      Гениально сформулировано.
                        0
                        Видимо не так-то просто эту ошибку найти на дизайне, пока оно до продакшена не дойдет и этим не начнут пользоваться. Давно бы уже никто ошибки в продакшен не пускал иначе.
                        0
                        Под вторым пунктом подписываюсь. И команду надо натаскивать: «Сначала подумай!»
                          0
                          В итоге, следуя за модой на технологии, вы получаете проект-зоопарк, где дружить технологии все труднее и труднее. Примеров много.


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

                          Only users with full accounts can post comments. Log in, please.