Comments 27
С удовольствием отвечу на вопросы.
Одна статья — в полной мере покрывающая многие аспекты. Поваренная книга командостроения. Спасибо огромное.
На всякий случай: сейчас из большинства наборов Лего можно собрать пару разных моделей по инструкциям, иногда — больше. Одну модель чаще можно собрать или из экспозиционных наборов (корабль в бутылке), или из строго-тематических(Валл-И). Фантазию ребёнка же ничего не ограничивает, как и 30 лет назад.
А КДПВ у вас — вообще не является официальным набором Лего.
А КДПВ у вас — вообще не является официальным набором Лего.
КДПВ вообще не моя, если честно. На слайдах или в видео видны оригинальные картинки, там официальные наборы.
Но, оффтопика ради, наборов лего вида «600 деталей и можно собрать 20 разных игрушек» я очень давно не видел, с собственного детства. И тенденция к специализированным крупным блокам в лего очень заметна. И вот смотрю на набор игрушек, которые надарили моим детям родственики — там почти всюду одна-две очень похожие модели. Конструкторы вида корабль/дом/самолет уже не делают.
Но, оффтопика ради, наборов лего вида «600 деталей и можно собрать 20 разных игрушек» я очень давно не видел, с собственного детства. И тенденция к специализированным крупным блокам в лего очень заметна. И вот смотрю на набор игрушек, которые надарили моим детям родственики — там почти всюду одна-две очень похожие модели. Конструкторы вида корабль/дом/самолет уже не делают.
С таким количеством разных игрушек из одного набора я совсем ничего не помню. Какой-нибудь #10183 давал примерно 10 разных моделей вагонов из одного набора, но это были уникальные случаи. А тенденции такой, на самом деле, нет. Lego System разделился на несколько направлений (City и прочие), но они точно такие же, ка и ранее. Множество мелких деталей. Крупные детали — это или детские наборы, или активно-игровые, где нужна максимальная устойчивость игрушки к постукиванию по стене и прочим активным действиям детей.
А с корабль/дом/самолёт — 722 это один из совсем ранних, когда практически всё строилось из одинаковых деталей. Разнообразие в деталях, всё же, принесло больше пользы для фантазии детей, нежели вреда. Впрочем, подобные и сейчас есть — наборы со словами lego classic или lego bucket.
А с корабль/дом/самолёт — 722 это один из совсем ранних, когда практически всё строилось из одинаковых деталей. Разнообразие в деталях, всё же, принесло больше пользы для фантазии детей, нежели вреда. Впрочем, подобные и сейчас есть — наборы со словами lego classic или lego bucket.
Вот собственно про движение от 722 и близких к нему к текущему Лего я и говорю. Когда вместо единообразия универсальных деталей появились гораздо более узко специализированные конструкторы с мелкими, но специфическими деталями. Когда появилось много узких линеек.
И про то, насколько разный инженерный подход стоит за старым и новым Лего )
А насколько разнообразие в деталях повлияло на фантазию — не знаю, у меня нет статистики. Но вообще сомневаюсь )
И про то, насколько разный инженерный подход стоит за старым и новым Лего )
А насколько разнообразие в деталях повлияло на фантазию — не знаю, у меня нет статистики. Но вообще сомневаюсь )
Отличная статья и техника к построению методологии в команде, под ситуацию. Спасибо за материал.
Как глоток свежего воздуха! Спасибо. В первый раз вижу текст про управление проектами, который наполнен (для меня) смыслом в каждом абзаце. А всего-то картинки Лего, который сын любит, привлекли. Неисповедимы пути господни.
Как человек с 25 килограммами современного конструктора LEGO в доме, вынужден опровергнуть ваше утверждение из начала статьи. По сравнению с наборами двадцатилетней давности, разумеется, произошёл ряд изменений, но это всё ещё конструктор, и никто не запрещает вам из деталей, скажем, поезда собрать грузовик, самолёт, корабль, дом, динозавра и робота — лишь бы фантазии хватило. А даже если и не хватает — у многих наборов всё ещё есть предусмотренные производителем альтернативные варианты сборки, кроме того, к вашим услугам сайты вроде rebrickable.com, где люди со всего мира выкладывают свои поделки в цифровом виде, в том числе и альтернативные варианты сборки существующих наборов.
У меня, например, есть набор, состоящий из более чем трёх с половиной тысяч деталей, 2018 года выпуска. Вы утверждаете, что все эти детали можно собрать только одним-единственным способом?
У меня, например, есть набор, состоящий из более чем трёх с половиной тысяч деталей, 2018 года выпуска. Вы утверждаете, что все эти детали можно собрать только одним-единственным способом?
Моя дочка упорно не хочет отрывать головы драконам, чтобы собрать гибрид. Так как он окажется сильно угробищнее. Что собственно подтверждают все ребрики — из полного (почти) набора Elves в основном предлагается собрать или кастрированную версию исходного дракона «зато быстро» или аппликацию «Кораблик» из десятка деталей.
Нет, конечно.
Но из одного произвольного набора собрать 20 разных игрушек уже не получается. Каких-то аналогов вполне обычному 722му уже нет. Конечно, из большой группы разных конструкторов можно собрать очень много всего нового (и статья, кстати, и про это).
Но если купить в магазине один произвольный конструктор, то количество возможностей будет заметно меньше, чем купив один конструктор лет 25 назад. Но смотреться результат будет симпатичнее.
Но из одного произвольного набора собрать 20 разных игрушек уже не получается. Каких-то аналогов вполне обычному 722му уже нет. Конечно, из большой группы разных конструкторов можно собрать очень много всего нового (и статья, кстати, и про это).
Но если купить в магазине один произвольный конструктор, то количество возможностей будет заметно меньше, чем купив один конструктор лет 25 назад. Но смотреться результат будет симпатичнее.
Мне в этой статье сильно не хватило методологии.
А чуть подробнее описать можно? Что такое методология, почему ее не хватило, что ожидали?
Я имел в виду, что в заголовке была заявлена методология. А методология видится мне чем-то более системным, упорядоченным, чётко выстроенным вокруг центральной идеи, чем эта статья. Здесь много разных интересных и полезных практических советов на разных этапах, но множество полезных практик не формируют методологию.
Говоря иначе, я думаю, что методология — это рецепт, которым можно воспользоваться. Здесь же, по сути, всё сводится к идее: «смело выбирайте наиболее подходящий вам практический подход для каждой стадии», и на примерах показаны некоторые частные решения. Для того, чтобы последовать этому совету и получить результат, нужен инженерный и управленческий опыт, нужно ориентироваться в мире практик и теорий, понимать чем они отличаются, какие имеют плюсы и минусы. Но человек, который всё это знает, и сам понимает, что каждая практика или метод — это лишь инструмент настройщика рабочего процесса.
Существует такой здоровенный и скучный стандарт CMMI, который во многом решает задачу, которая заявлена в статье. Он рассматривает процесс создания ПО и делит его на уровни зрелости — от полностью хаотичного до безумно организованного. В нём не описаны практики, конкретные советы и способы написания кода, есть только целевые задачи. Например, на втором уровне нужно обеспечить управление требованиями и управление конфигурацией — что-то в этом духе. (У них предполагается, что организация будет последовательно развивать свою систему, двигаясь к организации, но это не обязательно принимать как руководство к действию, можно просто понимать, чего тебе не хватает на очевидно твоём уровне).
Отличие этого стандарта от данной статьи в том, что им действительно можно воспользоваться как конструктором. Взять нужный уровень, посмотреть, какие процессы на нём должны быть в твоей системе управления разработкой, и под каждый процесс что-то внедрить. Этот набор целевых задач для каждого уровня согласован с существующими теоретическими достижениями в управлении, с процессными подходами и так далее, то есть, он хорошо работает как подсказка для конструирования.
Вот чего-то такого мне не хватило в статье, хотя в целом мне не с чем там принципиально поспорить, все практические советы написаны вполне по делу.
Говоря иначе, я думаю, что методология — это рецепт, которым можно воспользоваться. Здесь же, по сути, всё сводится к идее: «смело выбирайте наиболее подходящий вам практический подход для каждой стадии», и на примерах показаны некоторые частные решения. Для того, чтобы последовать этому совету и получить результат, нужен инженерный и управленческий опыт, нужно ориентироваться в мире практик и теорий, понимать чем они отличаются, какие имеют плюсы и минусы. Но человек, который всё это знает, и сам понимает, что каждая практика или метод — это лишь инструмент настройщика рабочего процесса.
Существует такой здоровенный и скучный стандарт CMMI, который во многом решает задачу, которая заявлена в статье. Он рассматривает процесс создания ПО и делит его на уровни зрелости — от полностью хаотичного до безумно организованного. В нём не описаны практики, конкретные советы и способы написания кода, есть только целевые задачи. Например, на втором уровне нужно обеспечить управление требованиями и управление конфигурацией — что-то в этом духе. (У них предполагается, что организация будет последовательно развивать свою систему, двигаясь к организации, но это не обязательно принимать как руководство к действию, можно просто понимать, чего тебе не хватает на очевидно твоём уровне).
Отличие этого стандарта от данной статьи в том, что им действительно можно воспользоваться как конструктором. Взять нужный уровень, посмотреть, какие процессы на нём должны быть в твоей системе управления разработкой, и под каждый процесс что-то внедрить. Этот набор целевых задач для каждого уровня согласован с существующими теоретическими достижениями в управлении, с процессными подходами и так далее, то есть, он хорошо работает как подсказка для конструирования.
Вот чего-то такого мне не хватило в статье, хотя в целом мне не с чем там принципиально поспорить, все практические советы написаны вполне по делу.
Спасибо за ответ.
Одна из важных для меня мыслей, которую я и пытался передать в докладе: четкие, системные, упорядоченные методологии обычно и/или очень дорогие или не решают именно ваших задач. Так как применять любые чужие методологии не понимая «почему» и «зачем» — это решать не свои задачи, а чужие. CMMI как раз хороший пример, соответствие стандарту ни как не соотносится ни с эффективностью компании, ни с качеством ее продуктов (по крайней мере положительной корреляции я не видел, возможно есть отрицательная). Кстати, вопрос «какие именно цели должен решать CMMI» весьма неочевиден, я вот не знаю ответа (ну, кроме зарабатывания денег компанией-создателем).
И как раз «под каждый процесс что-то внедрить» — это одна из самых опасных вещей, которые могут произойти, карго-культ как он есть.
Так что хорошо, что в моем докладе не получилось найти «методологию» в вашем понимании, что никто не собирается внедрять указанные там практики или подходы просто потому, что так написано. Это было бы для меня худшим результатом.
P.S. Увы, мне очень сложно всерьез говорить о «теоретических достижениях в управлении», хотя я знаю, что по этой теме даже реферируемые журналы выпускают и отнюдь не по кибернетике. Я все-таки слишком инженер.
Одна из важных для меня мыслей, которую я и пытался передать в докладе: четкие, системные, упорядоченные методологии обычно и/или очень дорогие или не решают именно ваших задач. Так как применять любые чужие методологии не понимая «почему» и «зачем» — это решать не свои задачи, а чужие. CMMI как раз хороший пример, соответствие стандарту ни как не соотносится ни с эффективностью компании, ни с качеством ее продуктов (по крайней мере положительной корреляции я не видел, возможно есть отрицательная). Кстати, вопрос «какие именно цели должен решать CMMI» весьма неочевиден, я вот не знаю ответа (ну, кроме зарабатывания денег компанией-создателем).
И как раз «под каждый процесс что-то внедрить» — это одна из самых опасных вещей, которые могут произойти, карго-культ как он есть.
Так что хорошо, что в моем докладе не получилось найти «методологию» в вашем понимании, что никто не собирается внедрять указанные там практики или подходы просто потому, что так написано. Это было бы для меня худшим результатом.
P.S. Увы, мне очень сложно всерьез говорить о «теоретических достижениях в управлении», хотя я знаю, что по этой теме даже реферируемые журналы выпускают и отнюдь не по кибернетике. Я все-таки слишком инженер.
Современные подходы к управлению — это вполне инженерная наука, я это вам говорю как человек, у которого в дипломе написано «инженер-менеджер».
И для меня странно, что инженер не хочет подойти к организации своего труда с инженерным подходом, методически.
И для меня странно, что инженер не хочет подойти к организации своего труда с инженерным подходом, методически.
Хм, возможно я просто не в курсе. А есть какие-то научные работы по менеджменту? Соответствующие критериям Поппера? Или что вы имеете в виду под «теоретическими достижениями в управлении»? Лучшее, что я видел — это была не слишком корректная статистика, хотя приходится опираться на нее, конечно.
Я не готов сходу подготовить какой-нибудь целостный реферат, но вот я посмотрел, навскидку, в википедии в статье «Менеджмент» более-менее здраво рассмотрена эволюция этой области знаний, в ней упоминаются нужные слова, можете ознакомиться.
Как у инженера, я думаю, у вас не возникнет вопросов в «научности» подходов к управлению, которые применяются в технике, которые в свою очередь являются смежными к теории информации и какой-нибудь кибернетике. Эти же методы управления, методы принятия решений и прочее давно рассмотрены и в более общих понятиях (выше которых начинается уже чистая философия, которая конечно наукой не является), и по возможности применяются там, где необходимо создать систему, состоящую не только из автоматов, но и из людей. Многие подходы к управлению системой из людей остаются теми же — системный подход, системный анализ, процессный подход. К менеджменту, конечно, добавляется область знаний, связанных с психологией и поведением людей, к которой можно относиться довольно скептически, но она является далеко не единственным его содержанием.
Все эти современные «теории управления» можно попробовать применить на практике и получить конкретные результаты. На основании множества экспериментов и делаются выводы о результативности и эффективности различных подходов, так что нынешние громоздкие обобщённые стандарты управления, типа ISO 9001 — это и есть зримое достижение менеджмента, как прикладной науки. Именно эти инновации, как считается, обеспечили «японское экономическое чудо» во второй половине двадцатого века и кое-какие чудеса помельче. Научным подходом к управлению занимались и в СССР, а тогда мало кого можно было заподозрить в недостаточно материалистичном взгляде на вещи.
В общем, теория и научный подход в управлении определённо есть, и знание теории может помочь достичь более высокой производительности труда и прийти к организации деятельности быстрее, не набивая шишек собственным лбом. Проблема в том, что многим кажется, что управление людьми — это нечто интуитивное, решаемое простым командным способом или лидерскими качествами (а это применимо далеко не везде), и изучением основ пренебрегают. Также в нашей стране традиционно считалось, что управление — это административная работа, и специальность менеджера — это пристанище для тех, кто оказался неспособен к технике. По катастрофически низкой производительности труда, проблема с которой тянется ещё со времен позднего СССР, мы можем видеть, что это не очень правильный подход к образованию.
Как у инженера, я думаю, у вас не возникнет вопросов в «научности» подходов к управлению, которые применяются в технике, которые в свою очередь являются смежными к теории информации и какой-нибудь кибернетике. Эти же методы управления, методы принятия решений и прочее давно рассмотрены и в более общих понятиях (выше которых начинается уже чистая философия, которая конечно наукой не является), и по возможности применяются там, где необходимо создать систему, состоящую не только из автоматов, но и из людей. Многие подходы к управлению системой из людей остаются теми же — системный подход, системный анализ, процессный подход. К менеджменту, конечно, добавляется область знаний, связанных с психологией и поведением людей, к которой можно относиться довольно скептически, но она является далеко не единственным его содержанием.
Все эти современные «теории управления» можно попробовать применить на практике и получить конкретные результаты. На основании множества экспериментов и делаются выводы о результативности и эффективности различных подходов, так что нынешние громоздкие обобщённые стандарты управления, типа ISO 9001 — это и есть зримое достижение менеджмента, как прикладной науки. Именно эти инновации, как считается, обеспечили «японское экономическое чудо» во второй половине двадцатого века и кое-какие чудеса помельче. Научным подходом к управлению занимались и в СССР, а тогда мало кого можно было заподозрить в недостаточно материалистичном взгляде на вещи.
В общем, теория и научный подход в управлении определённо есть, и знание теории может помочь достичь более высокой производительности труда и прийти к организации деятельности быстрее, не набивая шишек собственным лбом. Проблема в том, что многим кажется, что управление людьми — это нечто интуитивное, решаемое простым командным способом или лидерскими качествами (а это применимо далеко не везде), и изучением основ пренебрегают. Также в нашей стране традиционно считалось, что управление — это административная работа, и специальность менеджера — это пристанище для тех, кто оказался неспособен к технике. По катастрофически низкой производительности труда, проблема с которой тянется ещё со времен позднего СССР, мы можем видеть, что это не очень правильный подход к образованию.
В предыдущем комментарии ответил только на постскриптум, потому что не было времени.
Давайте считать (полагаю, что это не противоречит вашему видению) что методология — это организационная система, которая позволяет команде делать продукт результативно и с нужной степенью эффективности.
Вы говорите: методологии дорогие. Большинство методологий ничего не стоят. Консультанты берут деньги за их внедрение или консультации по ним. Если вы имеете голову на плечах, здравый смысл, и желание работать организованно, то можете пользоваться любой методологией бесплатно.
Вы говорите: методологии не решают именно ваших задач. Это чистая правда.
Методологии можно условно разделить на две больших группы. Первая группа — это нечто, выросшее из «взрослого» менеджмента, исходящие из теоретических предпосылок о проектном управлении. Это и управление напрямую по PMBOK или RUP-методологии, попытки сертифицироваться на соответствие ГОСТ Р 12207/9001 и прочему — всё это действительно тяжело и совершенно не подходит для того, чтобы взять и начать пользоваться.
Есть вторая группа методологий, и к ним относятся большая часть agile-историй, которые появились в ответ на тяжесть корпоративных управленческих систем. Это всякие Scrum, XP, TDD, тысячи их. Проблема таких практик в том, что они зародились в девелоперской среде, снизу, как наблюдение за удачно сложившимся конкретным процессом в каком-то конкретном проекте. Участники процесса попытались обобщить свои практики и составить из них методологию. Плюсом здесь является интуитивная понятность, лёгкость, и зачастую возможность непосредственного внедрения в дело. Как раз бездумное следование любой подобной методике и может привести к провалу, поскольку, как вы верно заметили, они наверняка не до конца отвечают именно вашим задачам.
Единственный правильный способ создания собственной, идеально соответствующей проекту методологии — это наличие в команде человека, способного деконструировать известные практики и создать на их основе то, что нужно. Потому что, несмотря на то, что все проекты уникальны по определению, проектная работа действительно разбивается на одни и те же процессы, хоть и меняется их интенсивность, состав ролей, потоки обратной связи и состав данных.
CMMI как раз является стандартом, которым можно пользоваться как подсказкой. Если вы чувствуете, что у вас постоянно возникают какие-то системные проблемы в работе, вы можете вдумчиво почитать про второй уровень зрелости и понять, что вам не хватает порядка в процессе деплоя или в структурировании потока требований от заказчика — и точечно принять меры по этому поводу. Никто не требует внедрять конкретных практик, софта или проходить сертификаций.
Другое дело, что CMMI написан весьма теоретически, для людей, изучавших управление. Мне кажется, и я в своё время пытался подойти к написанию работы на этот счёт, что такое усложнение совершенно не обязательно.
Именно поэтому я заинтересовался вашей статьёй. Конструктор методологии — это именно то, что нужно отрасли. Но для этого он должен быть легко применим, им надо иметь возможность воспользоваться, трансформировать с помощью него свои процессы, когда это нужно, и так далее. Если у кого-то получится сделать это, не привлекая тяжеловесной менеджерской теории процессного подхода и tqm, то это будет очень круто.
Давайте считать (полагаю, что это не противоречит вашему видению) что методология — это организационная система, которая позволяет команде делать продукт результативно и с нужной степенью эффективности.
Вы говорите: методологии дорогие. Большинство методологий ничего не стоят. Консультанты берут деньги за их внедрение или консультации по ним. Если вы имеете голову на плечах, здравый смысл, и желание работать организованно, то можете пользоваться любой методологией бесплатно.
Вы говорите: методологии не решают именно ваших задач. Это чистая правда.
Методологии можно условно разделить на две больших группы. Первая группа — это нечто, выросшее из «взрослого» менеджмента, исходящие из теоретических предпосылок о проектном управлении. Это и управление напрямую по PMBOK или RUP-методологии, попытки сертифицироваться на соответствие ГОСТ Р 12207/9001 и прочему — всё это действительно тяжело и совершенно не подходит для того, чтобы взять и начать пользоваться.
Есть вторая группа методологий, и к ним относятся большая часть agile-историй, которые появились в ответ на тяжесть корпоративных управленческих систем. Это всякие Scrum, XP, TDD, тысячи их. Проблема таких практик в том, что они зародились в девелоперской среде, снизу, как наблюдение за удачно сложившимся конкретным процессом в каком-то конкретном проекте. Участники процесса попытались обобщить свои практики и составить из них методологию. Плюсом здесь является интуитивная понятность, лёгкость, и зачастую возможность непосредственного внедрения в дело. Как раз бездумное следование любой подобной методике и может привести к провалу, поскольку, как вы верно заметили, они наверняка не до конца отвечают именно вашим задачам.
Единственный правильный способ создания собственной, идеально соответствующей проекту методологии — это наличие в команде человека, способного деконструировать известные практики и создать на их основе то, что нужно. Потому что, несмотря на то, что все проекты уникальны по определению, проектная работа действительно разбивается на одни и те же процессы, хоть и меняется их интенсивность, состав ролей, потоки обратной связи и состав данных.
CMMI как раз является стандартом, которым можно пользоваться как подсказкой. Если вы чувствуете, что у вас постоянно возникают какие-то системные проблемы в работе, вы можете вдумчиво почитать про второй уровень зрелости и понять, что вам не хватает порядка в процессе деплоя или в структурировании потока требований от заказчика — и точечно принять меры по этому поводу. Никто не требует внедрять конкретных практик, софта или проходить сертификаций.
Другое дело, что CMMI написан весьма теоретически, для людей, изучавших управление. Мне кажется, и я в своё время пытался подойти к написанию работы на этот счёт, что такое усложнение совершенно не обязательно.
Именно поэтому я заинтересовался вашей статьёй. Конструктор методологии — это именно то, что нужно отрасли. Но для этого он должен быть легко применим, им надо иметь возможность воспользоваться, трансформировать с помощью него свои процессы, когда это нужно, и так далее. Если у кого-то получится сделать это, не привлекая тяжеловесной менеджерской теории процессного подхода и tqm, то это будет очень круто.
Буду отвечать по пунктам, а то слишком сложно уже ориентироваться в большом тексте.
1. «Большинство методологий ничего не стоят». Это не так. Стоимость внедрения методологии, стоимость реализации ритуалов методологии, стоимость подготовки артефактов, стоимость поиска кадров — все это очень заметные расходы. Для некоторых методологий еще и требуется проведение пилотных проектов (RUP, например), что только увеличивает их стоимость. На этом фоне стоимость консультантов или специального софта уже совершенно незначительна.
1. «Большинство методологий ничего не стоят». Это не так. Стоимость внедрения методологии, стоимость реализации ритуалов методологии, стоимость подготовки артефактов, стоимость поиска кадров — все это очень заметные расходы. Для некоторых методологий еще и требуется проведение пилотных проектов (RUP, например), что только увеличивает их стоимость. На этом фоне стоимость консультантов или специального софта уже совершенно незначительна.
2. Про «взрослые» и «аджайл» методологии. Вообще, и те и другие пришли сверху, отнюдь не из «девелоперской» среды. Просто они отвечают разным наборам страхов (тяжелые — потеря управляемости и выхода за границы бюджета, легкие — увеличения time-to-market и «сделать не то»).
Но да, и те и другие не пригодны для конкретного проекта, нужно делать что-то свое. Про что и доклад )
Но да, и те и другие не пригодны для конкретного проекта, нужно делать что-то свое. Про что и доклад )
3. Про «конструктор».
Я не очень верю в «конструктор», больше в набор «шаблонов» с границами применимости и рекомендациями по внедрению. И воспитанию здравого смысла.
Конструктор очень быстро превратиться в еще один «карго-культ», как в него уже превращают и разнообразные agile-методики (которые, конечно, изначально были вполне здравыми). Карго-культ проще продавать, а в конечном итоге решает именно это.
А вот просто набор шаблонов продавать сложнее — из design patterns так и не сделали, к счастью, методики (хотя карго-культом до сих пор попахивает, но не слишком сильно), так что есть шансы.
Я не очень верю в «конструктор», больше в набор «шаблонов» с границами применимости и рекомендациями по внедрению. И воспитанию здравого смысла.
Конструктор очень быстро превратиться в еще один «карго-культ», как в него уже превращают и разнообразные agile-методики (которые, конечно, изначально были вполне здравыми). Карго-культ проще продавать, а в конечном итоге решает именно это.
А вот просто набор шаблонов продавать сложнее — из design patterns так и не сделали, к счастью, методики (хотя карго-культом до сих пор попахивает, но не слишком сильно), так что есть шансы.
dph
Как лучше масштабировать ваш подход?
Предположим, запускается новый проект, но сразу ясно, что он будет сильно расти.
Сейчас команда маленькая, скажем 3 человека, но мы понимаем, что через год уже будет 10 человек (и это уже практически 2 команды, не одна).
А через два года 20 человек, и это уже наверняка 3-4 команды.
Проводить «смену методологии» при каждой фазе росте? Отдавать выбор методологии на откуп тимлидам? Подобрать методологию так, что можно будет ее продолжать использовать и при росте? Какой-то другой вариант?
Как лучше масштабировать ваш подход?
Предположим, запускается новый проект, но сразу ясно, что он будет сильно расти.
Сейчас команда маленькая, скажем 3 человека, но мы понимаем, что через год уже будет 10 человек (и это уже практически 2 команды, не одна).
А через два года 20 человек, и это уже наверняка 3-4 команды.
Проводить «смену методологии» при каждой фазе росте? Отдавать выбор методологии на откуп тимлидам? Подобрать методологию так, что можно будет ее продолжать использовать и при росте? Какой-то другой вариант?
По Коуберну — нужно менять методологию при каждом переходе из клетки в клетку и тут я с ним полностью согласен: начало проекта втроем и развитие проекта в команде из 20 человек — очень разные вещи, требующие сильно разных подходов и методологий.
Так что менять методологию придется. Но так как рост заранее понятен — то можно к нему готовиться и делать переход максимально «гладким». А вот как именно расти — сильно зависит от людей и проекта.
Вообще процесс разделения одной команды на несколько — очень опасная штука, так как начинается (если специально с этим не бороться) соревнование между командами, спонтанное разделение на «нас» и «их». Может быть для группы в 20 человек не делить на отдельные команды, а просто потихоньку разным членам команды давать одного-двух человек в «ведомых». Тогда вместо 3-4 команд получится одна команда из 7-8 «звеньев», но при этом воспринимающая себя как нечто более «целостное».
Но все зависит, конечно, от конкретных целей и конкретных людей.
Так что менять методологию придется. Но так как рост заранее понятен — то можно к нему готовиться и делать переход максимально «гладким». А вот как именно расти — сильно зависит от людей и проекта.
Вообще процесс разделения одной команды на несколько — очень опасная штука, так как начинается (если специально с этим не бороться) соревнование между командами, спонтанное разделение на «нас» и «их». Может быть для группы в 20 человек не делить на отдельные команды, а просто потихоньку разным членам команды давать одного-двух человек в «ведомых». Тогда вместо 3-4 команд получится одна команда из 7-8 «звеньев», но при этом воспринимающая себя как нечто более «целостное».
Но все зависит, конечно, от конкретных целей и конкретных людей.
Sign up to leave a comment.
Методология как конструктор: инструкция по сборке