И еще немного мыслей на тему методологий управления проектами

    Последнее время меня часто записывают в лагерь противников методологий управления проектами (чаще имея ввиду agile/scrum/kanban). Это не совсем так. Я не против методологий, а против их фанатичного применения к месту и без, а также просто мистической уверенности в успехе после внедрения agile.

    Мне кажется, многие не понимают, зачем вообще нужна методология.

    Методология — это некий контракт (договоренность) между всеми участниками процесса. Это как язык жестов, правила дорожного движения, эсперанто или математические формулы. Отличие этих примеров от aglile/scrum/kanban в том, что они не подразумевают различных трактовок. В случае с aglile/scrum/kanban — каждая компания, и даже каждая команда имеет свой «канбан», который в большинстве своем вообще ничего общего с ним не имеет.

    По сути, нужно просто собраться всем участникам процесса и обговорить все нюансы. Это достаточно просто, например:

    1. Отчетность. Раз в неделю письменно, дважды в неделю (вторник и четверг) — по скайпу.
    2. Время реагирования. Для обычных писем — 4 часа, для тех, которые помечены как «важные» — 1 час (у многих компаниях это 15 минут).
    3. Обязанности. За технические вопросы отвечает Вася, за сервер — Коля, за чай на кухне — Петя.
    4. И т.д.

    К примеру, зачем писать на доске задачи, если они есть в жире или TFS. Если вы уверены, что с этим проблем не будет — смело исключайте этот пункт из «контракта». И заметьте, таким образом вы можете комбинировать best practices с разных методологий, подстраиваясь под конкретную команду и проект. Между прочим, это тоже agile, только без налета псевдо-элитности.

    Задача менеджера — не написать отчет о проделанной работе или найти исполнителей для проекта. Управление проектом подразумевает достижение цели при отсутствии необходимых ресурсов и полной или частичной неопределенности. Считаю, что знание методов управления рисками и основ бизнеса помогут среднестатической команде больше, чем внедрение agile.

    Дальше, любая методология управления предназначена, в первую очередь, для опытных специалистов. Таким образом, если у вас в команде есть начинающие специалисты или новые сотрудники (а такая ситуация была в каждой первой команде, где я работал), то внедрение гибких методологий пагубно скажется на производительности некоторых членов команды. Ведь джуниор будет думать: «ок, не успею в этот спринт, сделаю в следующем, так методология говорит» (хотя это и не так).

    Недавно задали вопрос: «а можно ли fixed price + agile?». Почему бы и нет. При правильном планировании. Но, опять таки, правильное и эффективное планирование зависит не от методологии, а от умения правильно планировать (извините за тавтологию).

    Еще одна проблема — использование agile/scrum/kanban там, где его использовать не нужно. Например, в проектах с очень ограниченными сроками или R&D. Или когда выполнение вашей задачи зависит не от вас или вашего начальника, а от внешних факторов, на которые вы влиять не можете. Примеров можно привести множество.

    В качестве выводов:

    1. Есть ли смысл внедрять методологии? Однозначно.
    2. Есть ли смысл тулить agile везде? Нет.
    3. Есть ли смысл на всех форумах и сайтах, где есть слово «методология» писать «agile всех спасет, а если нет — у вас руки из жопы растут»? Воля ваша, но со стороны вы выглядите, как минимум, глупо.
    4. Нужно ли читать книги о методологиях и ходить на agile тусовки? Однозначно, да. Но относиться ко всему услышанному нужно скептически и просеивать все мнения через ситечко.
    5. Ну и, наконец, какая методология лучше? Лучшей методологии нет. Лучшая методология — та, которая подходит вам, вашей команде и заказчику в конкретный момент и в конкретном месте и проекте.

    Спасибо за внимание!
    DevRain Solutions
    65,91
    Компания
    Поделиться публикацией

    Комментарии 24

      +3
      Саша, фишка в том, что следование какой-то методологии, а также перевешивание бумажек на стендапе — это часть социальной игры и атрибут рабочего общения. Это нужно для того, чтобы человек чувствовал себя в коллективе. Причем не в коллективе бездельников, а среди людей, которые вместе движут дело вперед. Можно без бумажек и следования выбранной методологии? Можно, но психологически это менее комфортно.
        0
        Эм, «Эндрю», фишка только и исключительно в том, чтобы проект был успешен, подразумевай это выполнение в срок, финансовый успех проекта или получение нужных данных в результате R&D.

        В энтепрайзе частенько — не всегда! — подходит итеративное планирование. Илт, как это называют любители англицких менеджерских книжек, эджайл. Но к черту эджайл, когда нужны надежность и стопроцентная предсказуемость. Или много R&D.
          0
          Комментарий чем-то напоминает мне Государственную Дуру. Чуждые англоязычные методологии не для нас — нам нужна стопроцентная уверенность и так далее и тому подобное. Результат тоже получается как у думцев обычно?
            0
            Вы обиделись? Извините, насчет «Эндрю» не сдержал улыбку.

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

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

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

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

              А рассуждения о том, что надо везде думать своей головой плохи тем, что на их счет нечего возразить.
                0
                очень хороший комментарий!
            0
            Про критерии успешности проекта, правда, но не для рядового программиста. Это не мотивирует лучше или усерднее писать код. Прямой зависимости показателей успешности для бизнеса на мотивацию программиста почти нигде нет. Пожалуй соглашусь. что есть польза от налаженного ритуала.
          +1
          А по моему топикстартер просто описал классический scrum ради scrum или «культ карго». Всё хорошо в нужное время и в нужном месте. Правда я противник эволюционного подхода построения «проектного контракта», т.е. когда начинают изобретать методы управления проектами в надежде, что когда-то это устаканится во что-то хорошее. На мой взгляд надо взять готовый метод, внедрить его а затем адаптировать под суровые реалии проекта/команды.

          P.S Заметил, что сейчас xfcnj любой проектный треш и помойку в работе оправдывать: «А у нас RUP».
            0
            На мой взгляд надо взять готовый метод, внедрить его а затем адаптировать под суровые реалии проекта/команды.
            А это не то же самое что
            … в надежде, что когда-то это устаканится во что-то хорошее
            ?

            Риск в том что старую систему сломаете, а новая «не полетит». И/Или люди разбегутся в страхе перед «новомодной хренью». Понятно, это вопрос времени и денег в конце концов, но кто готов это оплатить?
              0
              А это не то же самое что

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

              Риск в том что старую систему сломаете, а новая «не полетит». И/Или люди разбегутся в страхе перед «новомодной хренью». Понятно, это вопрос времени и денег в конце концов, но кто готов это оплатить?

              Тут надо четко понимать, для чего и как вы будете делать. Необходимость перемен должна назреть, а уж как правильно проводить орг. изменения — это уже классика, вот можно книгу об этом почитать полезную: pimenaus.livejournal.com/3450.html

              И всегда необходимо помнить притчу про Буриданова осла, который умер от голода так и не приняв решения из какого стога сена есть. Мы менеджеры и мы обязаны выдавать управленческие решения и нести за них ответственность.
            0
            Ещё хотел бы добавить…
            Мне импонирует scrum вовлечением «синих воротничков» в совершенствование процесса разработки и принятие решений. Это то что называют «бесконечным совершенствованием процессов». Это не какое-то изобретение в IT или конкретно scrum. Это то, что японцы называют Kaizen и родом оно из 50-х годов. И именно такие вещи как kaizen позволили поднять Японскую промышленность (напомню, что когда-то американцы относились к японским машинам так как мы сейчас относимся к китайским, такое было качество).
            Идём дальше… когда мы начинаем говорить о вовлечении «синих воротничков» в совершенствование процессов у нас пропадает менеджмент и появляется лидерство (обычными механическими способами мотивации такого не добиться). И именно лидерство позволяет сделать из «танцев с бубном» высокоэффективный инструмент, который может поднять продуктивность того-же самого коллектива разработки.

            Поэтому при выборе agile или не agile задайте себе два вопроса:
            1. Насколько быстро и дёшево вы хотите сделать проект.
            2. Если вы выберете agile, действительно ли вам хватит личностных качеств чтобы реально его внедрить.
              0
              Можно я не соглашусь с тезисом, что «agile он только такой, как сказали и никаких адаптаций?» Любая методология или техпроцесс всегда должен адаптироваться под реалии бизнеса.
                0
                Присоединяюсь к тезису. Если брать скрам, то Сазерленд говорит:
                У вас есть беклог?
                У вас есть таймбокс?
                Команда проводит собрания для синхронизации деятельности?
                Команда проводит ретроспективы?
                Если на всё ответить «Да!», то у вас есть скрам :)

                А остальное — это уже best practices, например я ещё ниразу не видел беклог в котором не было бы зависимостей между user story или отсутствовали user story не несущие маркетинговой ценности заказчику (т.н. технический долг)
                +1
                PS. Извините много буков, но хочется узнать Ваше мнение

                У меня лично к е%му аджайлу и Ко размытое отношение — от «мы пишем код, бл%» до осознания того что менеджерам и их боссам нужно более-меннее четкое представление о том, что будет завтра, и более-менее обоснованная уверенность, что условно послезавтра проект будет завершен. Конкретное отношение всегда формируется в конкретной команде и конкретном случае.

                У меня вообщем пару вопросов, очень хотель бы узнать ваше мнение.

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

                Доска — один из позитивных моментов, который я считаю полезным (при условии что все работают в одном офисе) — так все каждый день видят свой прогресс, свое место в общей упряжке и общий скоуп спринта — стимулирует и фокусирует внимание на том, что важно, т.к. идешь пить чай — доска маячит перед глазами, В распределенных командах, на мой взгляд, это чистой воды очковтирательство ПМа для себя самого, боссов и гостей. Тогда уже Гринхоппер, хотя куда ему до настоящей доски.

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

                Так не проще ли просто выпустить одну тоненькую книжечку или даже пусть это будет большой цветной постер, на котором будет всего пару строчек о том, что такое спринт, как измерять производительность и в конце добавить — все остальное — это ваш здравый смысл, если облажаетесь — пеняйте на себя, а не на Аджайл!?

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

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

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

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

                Ну так повторюсь — как хороший ПМ решает, плохой результат джуна был достигнут хорошим путем или плохим, и если хорошим — то как хороший ПМ в таком случе должен поступить? По мне так хороший ПМ должен взглянуть факту в лицо и принять факт, что он не учел риск просирания N времени при планированиии в начале спринта.
                  0
                  Преданности от джуна не требуется, а вот сидеть ночами и учить(ся) — да. Требуется. Иначе говно будет программист. Если он уже знает — почему джун? Если нет, почему прошлый вечер он потратил на контру/девочек, а не учил срочно, что там нужно знать?

                  Кстати, касается не только программистов.
                    0
                    Ну я и написал — я это бредом считаю, хотя я целиком осознаю, что это как бы помягче скаазть, не правосланая точка зрения.

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

                    А хороший или плохой программист получится — это тот еще вопрос. Не нострадамус, будущее читать не умею, но скажу так: мало, но с пользой часто лучше, чем много, но без толку. А если будете ожидать и требовать такого — то ИБД и получите.
                      +1
                      С одной стороны — да, человек никому ничего не обязан.

                      С другой стороны речь-то идёт не про «это ты почему ему задачи на новогодние праздники пишешь? Я ему уже кучу issue запланировал», а самообразование.

                      Условно говоря — джуниор — это такой то ли студент, то ли недоучка, который, вроде понимает по-человечески, но ещё говорить не умеет. Его ещё учить и учить.

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

                      Если консенсуса в этом вопросе не находится, то результат будет скорее отрицательный. Джуниор начнёт фалломорфироваться в офисный планктон, работодатель — в мудаковатого эксплуататора.

                      Повторю ещё раз: основная задача джуниора — не показать мастер-класс программирования, не решить все древние баги, которые «есть, но никто не знает как фиксить» и не сделать всю грязную работу по написанию JS'а или там, парсера чужого HTML. Его задача — доучиться под профессию и под специализацию кода (т.е. предметную область).

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

                        И где заканчивается эта конечность? Сколько самообразования нужно, чтобы признать его наличие? Сидеть вечерами за книжками как червь? Постоянно? Участвовать как Геракл в опенсорс проектах? Каждый вложит в это чтото свое, и если ПМ вложит в это чтото другое, чем сам джун — быть беде и разборкам на ковре. И кто в этом случае будет виноват? Джун, который самобразовывается, но не в рамках проекта или ПМ, который ожидает непонятно чего, о чем джун даже не догадывается? Но в большинстве то случаем в это вкладывается смысл, что джун будет ночами сидеть и делать таски по 14 часов в день если нужно. Вы предствляете себе собеседование, на котором человеку прямым текстом такое говорят что он обязан полгода работать сверхурочно и он соглашается? Обычно об этом просто умалчивают, и даже на прямые вопросы отвечают чтото вроде — ну иногда придется, вы же понимаете мы серьезная компания и должны укладываться в сроки.

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

                        В принципе вы правы, — переходная форма с нашими реалиями и подвляюще — студент. Но тогда надо смотреть реалиям в лицо — не жать все соки и не щелкать кнутом, а воспринимать его как человека, который по-человечески понимает, но говорить не умеет, и с высокой вероятностью свой срок завалит. Это уже, конечно, от проекта зависит, можно позволить такое или нет. Но если терпеть такое нельзя — нужно спросить ответственных людей, почему в команде, где такое терпеть нельзя, появился сидень, с которым надо нянчится.
                          0
                          Видите как вы плавно повернули точку зрения, мол, «делать таски по 14 часов в сутки». Я, вроде бы, говорил про самообучение.

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

                          Задача джуниора — изучить предметную область. По-крайней мере у нас, если джуниор не выучивается в разумный срок, мы с ним просто расстаёмся.

                          Поручать дешёвый кодинг дешёвому программисту, наверное, имеет смысл, но проблема в том, что наши «дешёвые кодеры» не могут соревноваться с индийскими товарищами.
                            0
                            Видите как вы плавно повернули точку зрения, мол, «делать таски по 14 часов в сутки». Я, вроде бы, говорил про самообучение.

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

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

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

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

                            Про индусов вообще не в тему — я говорю про оптимизацию расходов внутри существующей команды

                  0
                  Непонятен посыл статьи. Если автор пытается донести, что одни и те же инструменты могут быть неодинаково полезны в различных ситуациях, то разве это и так не очевидно? Или я что-то пропустил между строк?
                    0
                    Не пропустили. Основное сообщение автора: «Не превращаете agile в культ!».
                      0
                      Как бы да, перфоратор хороший инструмент, но обои им клеить не нужно
                    0
                    Автор сказал очень важную мысль о сути agile:
                    К примеру, зачем писать на доске задачи, если они есть в жире или TFS. Если вы уверены, что с этим проблем не будет — смело исключайте этот пункт из «контракта». И заметьте, таким образом вы можете комбинировать best practices с разных методологий, подстраиваясь под конкретную команду и проект. Между прочим, это тоже agile, только без налета псевдо-элитности.

                    Но есть два нюанса:
                    • Похоже, автор не понимает сути конкретных инструментов, предлагаемых agile фреймворками.
                    • Сомнения не являются причиной для того чтобы что-то не делать. Наоборот сомнения являются причиной провести эксперимент. Чтобы сомнения тебя уже больше не тревожили.


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

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

                    Самое читаемое