Методы Макдональдса не работают, что делать?

    Введение


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



    Почему методы Макдональдса не работают?

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

    В программировании мало повторяющихся задач, нет места для репродуктивной деятельности. После третьего повторения однотипного действия программист пишет утилиту, которая это действие автоматизирует раз и навсегда. Или находит Code monkey (иногда это рентабельней).

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

    Культ карго




    Вследствие того, что индустриальные методы управления оказались не эффективными, разработка ПО стала кузницей инновационных подходов к управлению производством. Waterfall, PRINCE2, CMMI, Oracle CDM, RUP, MSF, SEI PSP/TSP, Agile-семейство (XP, Crystal, Scrum, ASD, FDD и проч.) – это лишь небольшой перечень из того, что было изобретено и опробовано в нашей отрасли и обогатило практику проектного управления. Если в 4-ом издании PMI PMBOK об agile- подходах не было ни слова, то в 5-ой версии – 10 упоминаний.

    Вера в то, что существует единственный правильный процесс, заставила отрасль пережить «методологическое безумие». Безграничную веру руководства в методологию с большой буквы «М» — всеобъемлющую теорию того, как следует решать весь класс задач, возникающих в процессе производства. «Методологию создавали умные люди, а исполнители некомпетентны!» Методология принимает все решения, люди не принимают решения вовсе. Все процессы должны быть регламентированы. Все должно делаться по инструкции. Эксперименты запрещены. Применяемые методы ограничены. Тотальный контроль соблюдения регламентов. Внедрение всеобъемлющих KPI. Большая доля «сизифова труда».

    Не работает.

    Статистика показывает, что успех или провал проектов не коррелируют с методологиями, которые в них использовались. Одинаково успешно проваливаются проекты, которые управляются по методологии «как получится», RUP, agile или CMMI 5-го уровня.

    Все определяют люди.

    Что делать?


    То, что не существует единственного правильного процесса разработки ПО, означает, что в каждом новом проекте процесс должен определяться каждый раз заново, в зависимости от проекта, продукта и персонала, в соответствие с Законом 4-х П: продукт + проект + персонал = процесс.


    Рисунок Cartmendum

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

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

    Заключение


    Современное предприятие обязано относится к своим работникам так же, как к своим лучшим клиентам. Главный капитал современной компании – это знания. Большая часть этих знаний неотъемлема от их носителя – человека. Те предприятия, которые этого не поняли, не выживут потому, что не смогут быть эффективными.

    Сегодня эффективное предприятие – это сервис. Предприятие, с одной стороны, предоставляет услуги и продукты своим клиентам, а с другой, — рабочие места для наемного персонала.



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

    Цель предприятия, которое стремится к эффективности, сделать счастливыми не только своих клиентов, но и своих работников. У проекта разработки ПО сегодня не три, а четыре фактора успеха:

    1. Выполнен в соответствие со спецификациями.
    2. Выполнен в срок.
    3. Выполнен в пределах бюджета.
    4. Каждый участник команды уходил с работы в 18:00 с чувством успеха.

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

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

    Подробнее
    Реклама

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

      +9
      В Макдонольдс из людей делают роботов. А у программисты — это те, кто составляет инструкции для роботов. Естественно походы должны существенно отличаться.
        +17
        В целом все верно, хоть статья и капитанская.
        Если подходить к разработке как к разработке чего-то уникального, то да. Методы макдональдс не подходят.
        Но, к сожалению, мы живем не в идеальном мире. Подавляющее большинство программ, которые пишут сейчас программисты это типичные сайты. И вот там-то как раз творчества у программистов минимум. Все творчество в этих проектах у дизайнеров.
        Конвеер тут как раз подходит. Ибо организация довольно быстро вырабатывает свой стек технологий и пилит на них проект за проектом. Это уже не художники, а маляры. А работу маляров уже можно нормировать, что собственно и происходит. И таких программистов большинство. Это не плохо и не хорошо, это просто жизнь. Программы стремительно ворвались во все сферы деятельности и из творческой работы, программирование превращается в обычную работу. Процент творчество/процесс доходит до обычных соотношений
        других профессий, по мере развития технологий.
          +5
          Про сайты полностью согласен. Это массовое производство.

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

          ИМХО, это не так. Goole, Amazon, Yandex, Mail.ru — это не сайты. Это сервисы. Порой наукоемкие и уникальные. А еще есть продуктовая разработка и автоматизация бизнеса.
            +8
            Если бы, Goole, Amazon, Yandex и Mail.ru занимали хотя бы 70% рынка разработки, я бы с вами согласился.
            А так даже внутри этих компаний, этим самой наукоемкой разработкой занимаются хорошо если половина разработчиков. А в реале я думаю процентов 30 максимум.
            +2
            А к игроделу это применимо?
              +1
              Да, но естественно не к любым проектам.
              Для большинства мобильных, флеш и им подобных проектов так и есть. Игры в сторах на 90% братья близнецы.
              А это и есть, то самое, массовое производство.
                +2
                В высшей степени. Посмотрите на кучу «веселых фермеров». Если посчитать долю оригинальных разработок в области игр, то игрострой покажется еще большей рутиной, чем клепание сайтов.
              +58
              К сожалению — не всё так однозначно. Возможно мне стоит написать отдельный пост на тему конвейерного метода организации программирования. И назову её «Домик из говна. Правильный способ производства ПО в индийских условиях».

              У меня был личный опыт участия в подобном, в бытность стажировки в Индии в 2005 году. Сейчас эта структура называется Aricent, тогда это был Flextronics Software Systems (CMMI-5).

              Огромный проект для телекома, целевая платформа Solaris 8. Его делает большая толпа (>120 человек) малоквалифицированных исполнителей (что всем очень понравится — индусов) с тоненькой прослойкой тимлидов уровня нормальных программистов (тоже индусов) и индусский менеджмент. Плюс группка стажёров, заброшенных с Украины и Беларуси чтобы оторвать кусок проекта в ту сторону.

              Был устроен фабричный конвейер в чистейшем незамутнённом виде:
              — Перед включением в проект — ПТУ. «Дети, знакомьтесь — это проект, проект — это дети». Серия тренингов об архитектуре проекта и всему инструментарию сверху до низу (включая vim, version control ClearCase, разбиение на модули, как входить на девелоперский сервер и т.д.), плюс вводная как это должно реализовываться. Для самого конечного исполнителя с сонным выражением лица стоящего в строю.

              — API и архитектура — прибиты гвоздями заранее.

              — Система спроектирована таким образом, что всё сделано через FSM. Исполнители кодят функции переходов между состояниями И ВСЁ. В худшем случае производительность участника можно оценивать количеством написанных функций в день. Их сотни и они одинаковые. Индусы радостно копипейстят одно и тоже.
              непридуманный диалог со standup daily meeting:
              PM — Ритика, сколько функций ты вчера написала?
              Ритика — 17
              PM — Плохо! А ты Вишну?
              Вишну — Я написал 36 функций!
              PM — Молодец, Вишну! Всем тоже писать 36 функций в день!


              — проект для рядового исполнителя разбит на стадии:
              а. 2-3 месяца кодим, и только кодим. Вся команда кодит. 120 человек. Даже компиляция проверяется весьма эпизодически
              б. 2 недели — юнит тесты. За программирование — бьют по рукам, только пишем тесты. Code coverage проверяется и прочие вещи.
              в. 2 недели системная интеграция, заставляем модули работать вместе

              В итоге через полгода работы (включая фазы подготовки людей, проектирования и непосредственно реализации) — имеем первую версию системы. За полгода 120 человек написали маштабируемую 3G VoIP телефонию (HA, расширяемость, все дела). На тестах первая итерация системы поддерживает только 2 (!) пользователей и всегда зависает на 35 звонке. Тимлиды возвращаются с показов заказчику седыми.

              Но… Начинается следующая итерация «проектирование» ->«кодинг»->«юнит тестирование»->«системная интеграция». И я полностью уверен, что после 5 итерации система заработала в полном обьёме. Её тупо массой задавили и грамотным использованием неквалифицированных исполнителей в правильно выстроенным для них процессе.

              Мои аплодисменты менеджменту и проектировщикам. Как выстроить людей, допускающих ДИЧАЙШИЕ косяки и особенно не умеющих программировать, в конвейер. И получить результат.
                +18
                Наверно этот метод надо назвать «Атака Зомби»
                  +6
                  Я предлагаю ещё более крутое название. «Атака Браминов-Зомби».

                  100% программистов в Aricent были из касты браминов. Это связано полагаю с невозможностью получить высшее образование представителям других каст. Плюс пониженная доступность нормальных школ, из которых можно поступить на IT-специальности.

                    0
                    С тех пор много воды утекло. Браминов на покрытие нужд аутсорсинга давно уже не хватает.
                    0
                    насчёт зомби — классическая конвейерная потогонка.

                    Я приходил в Guest House после работы и падал в кровать лицом вперёд не раздеваясь. И засыпал мгновенно.
                    +3
                    Спасибо. Оч. интересный опыт.
                    Возможно мой пост слишком категоричен. Конечно можно и конвейер построить. Только вот вопрос, насколько он будет конкурентоспособен на рынке?
                      +2
                      Для действительно больших и масштабных проектов — мне кажется вполне конкурентоспособен. Для типичных аутсорсеров из Восточной Европы и ex-USSR — они просто не смогут собрать такое дикое количество исполнителей на один проект. Плюс эти исполнители сравнительно малооплачиваемые и очень держатся за свою работу (рядом с офисом на улице на тротуарах спят бездомные, за стеной офиса — свалка, где коровы и бомжи конкурируют за отбросы).

                      Приемлимого качества продукта в целом с помощью такого модифицированного итерационного waterfall-конвейера можно добится к 4-5 итерации. Есть ниши для подобных долгоиграющих проектов. Как писал незабвенный Брукс в «Мифическом человеко-месяце» — на больших проектах на первый план выходят вопросы организации труда и взаимодействия внутри и между проектных команд, входящих в коллектив проекта.
                        +8
                        А насколько малооплачиваемы?

                        Давайте проведем мыслительный эксперимент. Пусть средняя ставка в час у тех 120 разработчиков 3 бакса. Вместо них можно собрать 12 человек со средней ставкой 30 баксов в час. Такую команду можно легко собрать на территории России и ближнего зарубежья. Я предположу, что это будет очень сильная команда, и за 6 месяцев они могут сделать не меньше той толпы индусов. При этом будет сразу экономия на сопровождающий ресурс — менеджмент и аналитиков (которые обязаны разжевывать требования до диаграмм выполнения кода). Я уже не говорю про другие факторы типа тех долга, стоимости внесения изменений, количестве issues на 1000 строк кода.
                        Что скажете? Похоже на правду?
                          0
                          Похоже, но этих 12 супер-старов должен кто-то прособеседовать и, скорее всего, их придется «вынимать» с какой-то другой работы, где он долго работает. Пойдет ли человек на 6 месяцев в непонятный проект на таких условиях? Должно быть не 30 а все 50.
                            +5
                            Продолжу мысленный эксперимент.
                            — Из набранных 12 человек трое пропадут в течении первого месяца. Просто не выйдут на работу и все.
                            — Второй месяц все будет тихо и команда, возможно, даже будет работать на отлично. Только придется чуть сдвинуть сроки, потому что в команде теперь не 12, а 9 человек.
                            — На третьем месяце трое попросятся в отпуска, из которых вернется только два человека (третий таким хитрым образом проскочил испытательный срок в другой конторе). Вы в срочном порядке начнете искать замену недостающим- ведь из планировавшихся 12 работников осталось 8 человек. Пока вы будете их искать вам придется отвлекать уже сверх нормы загруженых членов команды от проекта на интервью, планирование и пере-планирование (на менеджерах же сэкономили, пусть сами программисты теперь отдуваются). Ваши программисты вместо программирования будут сидеть на минингах и охреневать от скуки, пока вы с их помощью решите кто будет закрывать задачи, которые должны были закрывать ушедшие работники. Кстати, сроки опять сдвигаются и на этот раз уже значительно — помимо неполной команды, вы еще тормозите работу пере-планированием и интервью.
                            — На четвертом месяце путем героических усилий вам удается нанять двоих, предложив им повышенную зарплату. Узнав о реальной разнице в оплате между новичками, и теми, кто начинал проект, еще один ушел в другую контору на похожий проект, а трое других вытребовали с вас повышение зарплаты. Правда вы нашли еще одного работника на зарплату ушедшего, хоть у него уровень и не такой высокий, как у остальных.
                            — На пятом месяце вы имеете пять человек, которым вы платите завышенную зарплату, четырех недовольных тем, что «им подняли, а нам нет», три новых работника, постоянно пристающих к вам с вопросами «зачем так, давайте переделаем», уже окончательно сорванные сроки, распухший бюджет (вы же увеличили зарплату фактически половине команды), одного новичка, который «не тянет», озлобленных клиентов (или Upper management, если проект внутренний). На этом месте вы осознаете, кто качество кода, который неполная команда выдавала последние два месяца несколько не соответствует ожиданиям. С другой стороны их сложно упрекать — каждый работал за двоих или даже троих.

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

                            :)
                              0
                              Проект не будет стартовать сразу с 12 разработчиками. Для них всех не будет работы. Вначале будет сформирован костяк из сеньоров для проработки требований и формирования архитектуры, а потом потихонечку будут подключаться рабочие руки.
                              Я думаю, что в Индии можно словить всех 120 ребят быстро, но подготовка нужна серьезнее.

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

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

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

                              По поводу работы команды в тихаря, вопросов по тех деталям, отношений — тимлид и сеньоры должны быть опытными и сильными, это да… Agile… А в общем то эти проблемы встречаются всюду и успешно решаются.

                              Мне кажется, Вы сильно сгустили краски :)
                              И даже с такими рисками мне было бы страшнее начинать проект с той толпой индусов. :)
                                0
                                Мне кажется, Вы сильно сгустили краски :)

                                Я, в общем-то, почти в шутку описал реально встечавшиеся мне проблемы :)
                              0
                              Непохоже, начиная с «можно собрать 12 человек со средней ставкой 30 баксов в час». Проблемой всегда было даже качественных 3-4 исполнителей найти. Я всегда работаю напрямую с HR своих компаний (хобби такое, неофициально), и знаю каково положение на рынке труда (очень перегрет, много лет подряд, проектов больше чем возможных исполнителей).

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

                              Менеджмента на нашем Zerg Rush было не больше чем на типичном проекте разработки в западном стиле. Аналитики — тоже не так много, документация верхнего уровня написана ими, документация уровня подпроекта — тимлидами, документация уровня модуля — рядовыми исполнителями. Так уж получилось — что я документацию вычитывал. Помню, что качество линейно зависело от должности автора доки в иерархии компании :).

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

                                Рядом с офисом на тротуаре спят бездомные. А за стеной вокруг офиса — находится шикарная свалка на N гектар, где за пищевые отбросы конкурируют семьи бомжей и коровы. Я не сгущаю, достаточно было подняться на крышу офиса конторы в Гургаоне (город-спутник Дели) — чтобы получить вид на то как живёт остальная страна. Думаю это стимулирует.
                                  0
                                  Я думал, у браминов деньги есть и без вкалывания по 14 часов…
                                    0
                                    Отдельные безумно богатые семьи есть, но не все же 2-5 миллиона человек, принадлежащих к этой касте.
                                    Наши ребята все скорее напоминали выходцев из европейского среднего класса (внешне и по воспитанию).

                            +9
                            Консультировал я похожий кейс. Там, к сожалению, массой можно давить до определенного предела. Потом проблема сложности разрастается на харчах технического долга, отращивает несколько голов с большими пастями и начинает откусывать разработчикам руки-ноги-головы: попытка добавить что угодно занимает недели, система падает непонятно где и непонятно почему, в архитектуре не разбирается уже никто. На такой стадии обычно увольняются несколько ключевых разработчиков, после чего проект переписывается с нуля другим подрядчиком и история повторяется :).
                              +2
                              Границы применимости — есть у любой методики разработки.

                              Кстати, я не упомянул, но на весь проект была документация, которую заставляли писать.
                              Как и у всего проекта в целом — её качество падало в зависимости от уровня. Высоко-уровневые архитектурные вещи — описаны отлично, чем ближе к коду — тем хуже и out of date. Ну и код — то хуже всего :).
                              +7
                              Ключевой момент — проектирование системы, API и FSM. Кто это сделал? «Тимлид уровня среднего разработчика» на такое не способен. Спроектировать API так, чтобы его смогла заимплементировать толпа в 120 мартышек — это очень и очень нехилый скилл, и такое проектирование требует очень и очень много времени. Думаю, что не ошибусь, если скажу, что работа архитекторов этой системы стоила дороже, чем работа 120 «программистов».
                                0
                                Архитектура была не очень сложная. И, судя по всему, типовая для этой конторы. Мне показалось что они уже делали подобные проекты. Было в составе одна или две звезды разработки, которые обитали где-то на верхних уровнях иерархии и спускали сверху правильные стратегические решения. Плюс менеджмент, меня больше всего удивил менеджмент сего зерг-раша. Вот где скилл! Как принципиально не-западное мышление и поведение исполнителей интегрировать в западную модель разработки с предсказуемыми рисками и сроками.
                                +12
                                Это ж нейросетка на индусах! Строим софт генетическим методом!
                                  0
                                  Описано всё забавно и очень правдоподобно, но я отказываюсь верить, что «после 5 итерации система заработала». Точнее, что в результате получилась «система», а не шмот переваренных пельменей, красиво обложенных тестами, которые только и проходят на подобраных данных.
                                  Если вы делаете механические часы, как можно надеяться на овальные шестерёнки и «шлифовку кирпичом»? Хоть всю систему по блокам опиши, некачественный код даст о себе знать — не сейчас, так при развитии проекта.
                                  У меня тоже был «кооперэйшн» с индусами, которые готовы слепить хоть lamborgini! Это только потом ты узнаёшь, что двери — из фанеры, петли — снизу, а закрывается щеколдочкой изнутри — примерно так выглядела их работа в первой итерации. После разноса щеколдочку перенесли наружу, петли убрали вообще, а вход был через sunroof. Больше мы этих макак не нанимали. :)
                                    +1
                                    Насколько мне известно — заказчик (крупный вендор производящий телекоммуникационное оборудование) систему принял. И продолжает сотрудничество с нашими любимыми индусами. Не путайте качество работы конечных исполнителей с качеством организации разработки системы в целом. Зерг-раш на тестирование тоже думаю проводился неоднократно.

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

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

                                    Пару крутых историй из хроники той поездки:
                                    1. Молодой, красивый и инициативный парень Gunjan, в компании с 3-4 подельниками, по telnet хуячили под одной учётной записью и в одной рабочей копии несколько недель изменения в базовое API. Без коммитов, за несколько недель до релиза. Но их поймал наш любимейший Ramakrishna Pulivendla (PM этого модуля), и раскалённой кочергой внутри-анально принудил к коммиту. Гунджан с подельниками вынужден был править последствия своего авантюризма в режиме 14 часов в день/7 дней в неделю. И из офиса они в понедельник, 12 декабря, в день релиза первой итерации, вышли в 6 утра.

                                    2. Вишну получил задание — надо в логах сделать перенос строки. Чтобы между записями была отбивка 1 строка. Вишну открыл файл с сообщениями (да, система правильно спроектирована), и добавил в 200 сообщений '\n'. Я уверен что вручную, т.к. замене по регулярным выражениям в vim их перед стартом проекта не учили. Этот триумф усидчивой жопы над мозгами увенчивает факт, что было достаточно в макрос вывода логов добавить '\n'. Но, что характерно, задача была решена и это решение даже ничего не сломало :).

                                      0
                                      Некачественный код — заложен в управляемые риски проекта и преодолевается примивитизацией операций, используемых конечными исполнителями. Это высокий полёт по управлению проектами, без всякой иронии.
                                      У меня обычно хороший код появляется из плохого в результате рефакторинга. А тут сразу проектируется хорошая структура. Высокий полёт, оценил…
                                    0
                                    — API и архитектура — прибиты гвоздями заранее.

                                    — Система спроектирована таким образом, что всё сделано через FSM. Исполнители кодят функции переходов между состояниями И ВСЁ
                                    Ну с такими вводными, когда каркас, считай, сделан, то и можно делать остальное методом «атака брамино-зомби»…
                                    — проект для рядового исполнителя разбит на стадии:
                                    а. 2-3 месяца кодим, и только кодим. Вся команда кодит. 120 человек. Даже компиляция проверяется весьма эпизодически
                                    б. 2 недели — юнит тесты. За программирование — бьют по рукам, только пишем тесты. Code coverage проверяется и прочие вещи.
                                    в. 2 недели системная интеграция, заставляем модули работать вместе
                                    Я как-то практиковал подобное в уменьшенном масштабе на микропроекте в одно лицо — неделю тупо кодил в текстовом редакторе, потом компилировал и отлаживал… Методика сработала, но больше я так не делал.
                                    +3
                                    Методы Макдональдса в программировании не работают потому что программирование это проектирование, а не производство.
                                      0
                                      Мир прекрасен и удивителен. В нём масса вещей, которые могут показаться невозможными.

                                      Например программирование организованное как конвейерное производство (см мой большой комментарий выше) :).
                                        0
                                        Конвейер может быть и не на производстве. Например Kanban подход, успешно применяемый в ИТ — чисто конвейерный подход.

                                        Но вот чего точно не надо делать — пытаться адаптировать производственный конвейер, как в макдаке, под задачи разработки, не взлетит.
                                      0
                                      Скрытая реклама R-Style?
                                      0
                                      Буквальное следование определенной методологии в управлении проектом — это отличный способ надеть розовые очки и снять с себя ответственность. С другой стороны, менеджеров, способных организовывать эффективные процессы вне этих рамок — крайне мало. Это более тонкий и умный подход и средний «восторженный хипстер» просто завалит проект. И далеко не каждый проект может вызвать достаточный уровень мотивации, подходящей для супер-гибкой методологии управления. А так — все верно конечно написано.
                                        +1
                                        >Статистика показывает
                                        Можно взглянуть на статистику?
                                        0
                                        Соглашаясь с автором в целом…
                                        Боюсь спросить, а что автор понимает под репродуктивной деятельностью и почему ей нет места? (программисты тоже люди и ничто человеческое им не чуждо). 8-)
                                          0
                                          Человечеству известны два вида деятельности. Репродуктивная деятельность (труд) является слепком, копией с деятельности другого человека либо копией своей собственной деятельности, освоенной в предшествующем опыте. Такая деятельность, как, например, труд токаря в любом механическом цеху, или рутинная повседневная деятельность менеджера-управленца на уровне раз и навсегда усвоенных технологий. Продуктивная деятельность (творчество) — деятельность, направленная на получение объективно нового или субъективно нового (для данного работника) результата.\

                                          Как-то, так.
                                            +1
                                            Да, это я съел чего-то, наверное. Спутал с репродуктивной функцией. А насчет деятельности, скоро напишу более четкую статью тут с опросом. Тогда и посмотрим, кто есть кто на хабре.
                                          0
                                          программирование отличается от индустриального производства и в нем методы управления Макдонольдса не работают
                                          Думаю, более адекватной, чем индустриальное производство, аналогией для программирования являются научно-исследовательские и опытно-конструкторские работы…

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

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