Управление в стиле Agile. Как создать самоуправляемую команду в ИТ проекте

Публикация № 1299781

Методология - Методология управления разработкой - Agile (XP, SCRUM, Канбан)

Про Agile только на конференциях Инфостарта сказано уже так много, что, кажется, сложно кого-то удивить. Но руководителю компании Rodionov consulting Денису Родионову это удалось, потому что он в своем докладе на Infostart Event 2019 Inception рассказал не только сухую теорию, но и примеры из собственной практики.

Сегодня мы поговорим про гибкие методологии управления. Это сейчас достаточно популярная тема, я бы сказал даже, это «горячий пирожок» на рынке консалтинга, на рынке управления.

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

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

 

О себе

 

 

Пару слов о том, как я попал в эту сферу – как обычно, случайно, «я не хотел, меня заставили».

  • Мой первый опыт применения Agile-технологий был стихийный: я в 2003 году управлял сервисным центром и столкнулся с проблемой, что некоторые сервис-инженеры не любят взаимодействовать с клиентами. Они отлично чинят компьютеры, но их сложно заставить перезвонить, пообщаться с клиентом, продиагностировать проблему удаленно. У них все время были причины не звонить: например, «я сейчас занят», «я сейчас на другом объекте» и т.д. У клиентов из-за этого падало субъективное ощущение полезности, им казалось, что мы не работаем, мы не занимаемся их заявками, их проблемами. Было очень много нареканий. Я тогда пытался найти какое-то решение, и неожиданно нашел модель, при которой сервис-инженеры звонили клиентам сами – по факту, эта модель была основана на подходах Agile (правда, я их тогда так не называл). Позже я подробнее расскажу, как это получилось сделать. Но тогда я увидел реальный результат – потому что если раньше клиенты субъективно оценивали нашу работу на 40-60% (что для сервисного центра очень плохо), то после применения Agile-технологий в течение 3 месяцев показатель удовлетворенности клиентов вырос до 90%.
  • В дальнейшем я неоднократно применял эту методику в других командах. Преимущественно я работал в ИТ – опыт у меня айтишный. Я работал и на стороне клиента (одно из самых крупных внедрений в компании Мегафон, где я был руководителем отдела автоматизации), и на стороне франчайзи (мы делали проект по автоматизации на 1С для Главстроя).
  • Консалтингом по Agile я занимаюсь с 2013 года. Я помогаю внедрять гибкие методологии.

 

О чем доклад

 

 

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

 

Типы систем управления

 

 

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

Что касается иерархической системы, то речь идет о всеми любимой школе научного менеджмента, Фредерика Тейлора (1895 год) – системе, которая дала миру бизнес-процессы, конвейер и все, что мы любим и умеем. Это тогда было изобретено и научно описано.

А гибкие методологии как школа человеческих отношений (так эта тема в научной среде называется), родились чуть позже. Первая научная работа на эту тему была в 1924 году, когда американский ученый Элтон Мэйо с коллегами проводил большой эксперимент (Хоторнский эксперимент) в попытке выяснить, как мотивировать рабочих, от чего зависит производительность. Они тогда нашли приемы, позволяющие повысить успешность в работе с людьми – то, что мы сейчас называем гибкими методологиями. Открытия, которые они сделали (что людей надо мотивировать, включать, следить за тем, чтобы они были заинтересованы), для 1924 года, для тогдашней корпоративной Америки, звучали авангардно, и поэтому это «никто не купил». Продолжение эти методологии получили примерно в 1960 году, когда в мире появилось очень много людей интеллектуальных профессий – инженеры, врачи, дизайнеры – такие направления, где традиционные подходы перестали работать, и капиталистический мир понял, что с этим надо что-то делать. Когда у тебя с проекта уходит ведущий инженер, ты можешь потерять половину бизнеса – это наши современные реалии. В то время и начал появляться спрос на гибкие методологии.

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

Примеры иерархической системы:

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

Все эти системы организации труда, организации людей построены на иерархии.

Гибких систем управления чуть меньше.

  • Это социально-сетевая, она же слабо матричная. По этой системе, например, был устроен ранний Facebook и ранний Google. Это очень модная система для западных стартапов, когда есть одна команда, которая делает что-то одно, и есть другая команда, которая делает что-то другое, но вместе эти команды образуют сеть. Если у них есть правильный протокол общения, это эффективно работает. Если его нет, система рушится. Условно говоря, если в иерархии есть руководитель и под ним 5 команд, и он им что-то раздает, в гибких технологиях команды самоорганизованные, у них нет руководителя.
  • Модель MLM похожа. Но там, несмотря на иерархию, есть определенные протоколы, и каждое звено в этой сети – самостоятельное.
  • Холократическая система управления – на ней работает, например, банк «Точка». У меня было два внедрения холократической системы, это достаточно тяжелый процесс с точки зрения внедрения, но он реально очень эффективный с точки зрения компании.
  • Бирюзовая организация – это подвид холократической системы, который основан на работах по спиральной динамике. Это в большей степени методический коммерческий продукт. Но бирюзовая организация, по сути, – организация, которая использует гибкие методологии управления.

 

Отличия иерархической и гибкой системы

 

 

Один из ключевых факторов отличия иерархической и гибкой систем – роль лидера.

  • Если мы берем, допустим, отдел разработки, то в иерархической системе есть администратор, который раздает задания и проверяет их статус.
  • В гибкой методологии у нас вместо администратора будет модератор, который предлагает взять задачи. Обычно здесь на этапе внедрения возникает больше всего страхов и сопротивления – когда мы начинаем разговаривать про гибкие методологии, руководители чаще всего боятся, что будет сложно договариваться, что никто не согласится выполнить какую-то задачу. Но поверьте, эти страхи не оправданы. Я ни разу такого не видел, так не бывает, чтобы люди, смотря на пул задач, все от всего отказались. Это больше страх, чем реальность. Да, есть нюансы. Например, мы делали так: есть стэк задач, ребята выбирают, кому что нравится, но какое-то небольшое количество задач подвисает. Мы их тоже распределяем, но стараемся не навязывать, предлагаем разобрать оставшиеся задачи добровольно, и объясняем, что иначе у нас будут проблемы. И обычно это всегда работает.

Второй фактор – это ответственность.

  • В иерархической структуре ответственность на руководителе – если что-то не получилось, то отвечает за все руководитель.
  • В гибкой методологии ответственность на членах команды. С этим тоже много вопросов и проблем. Получается, если кто-то один не сделает, то пострадает вся команда. Да, пострадает вся команда, но есть один нюанс. В гибкой методологии один из ключевых принципов – это распределение информации, и все члены команды знают, что мы делаем и к чему мы идем. Если в иерархии делиться конечной целью необязательно (можно просто поставить задачу, проверить и интегрировать результат в общую цель), то в гибкой методологии все знают, что будет, если общая цель не будет достигнута. К примеру, мы делали автоматизацию, команда очень небольшая – три человека, и у всех было одинаковое понимание, какие у нас дедлайны. И не только менеджер проекта это знал, но и программист понимал, что если не выполнить работу вовремя, то все, что он сейчас делает, бесполезно. И методолог тоже это понимал. Задача руководителя (а здесь, скорее, модератора), заключается в том, чтобы все одинаково понимали сроки и цели. Как ни парадоксально, но когда люди реально понимают ответственность, понимают, что им за это будет или не будет, это давит намного сильнее, чем руководитель проекта, который ходит и всех «пинает». Понимание, осознание того, что «если я подведу, и из-за меня встанет весь проект», оказывает на людей чудовищное давление. Поэтому если говорить про гибкие методологии, это достаточно жесткая система с точки зрения психологического давления. Помимо свободы, она на самом деле сильно нагружает людей.

Про открытость информации я уже немного сказал:

  • В иерархии информация может быть и открытого, и закрытого типа – вы можете не делиться с людьми, зачем им это делать, вы просто даете задачу.
  • В гибких подходах, если вы не делитесь информацией, у вас проект не взлетит, потому что фактора давления не будет. В практике я часто встречал такой страх: допустим, мы написали огромный список из 300-400 задач, где были даже такие странные задачи, как «купить холодильник в офис», «поставить теннисный стол», «поставить цветы в офисе». Вначале ребятам было страшно, они спрашивали – неужели и эту ерунду тоже надо планировать? Но когда началось распределение задач, и люди начали реально разбирать задачи, то те, что были связаны с цветами и холодильником в офис, никто так и не взял. Потому что одно дело накидывать задачи в общий пул, а когда появляется вопрос ответственности, когда человек понимает, что сейчас на это подпишется, что ему надо будет что-то сделать – это уже сложнее. Это тоже такой интересный момент, которого вначале не видно, но на практике он есть. Мы достаточно сознательно все выбираем, и проблем с выбором у людей никогда не бывает.

Контроль. Принципиальное отличие состоит в том, что

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

 

Качество систем управления

 

 

Зачем внедрять гибкие методологии?

Повышается производительность. Есть такая концепция – High performance teams. Она разработана в 1950 году в одном из британских университетов, которые занимались вопросами человеческой производительности. Ученые проводили определенные измерения относительно того, как повысить производительность команды, за счет чего и т.д. В итоге получилось, что гибкие методологии дают в 2 раза больше производительности, чем иерархические.

В моей практике был случай, когда мы написали информационную систему, а потом провели бенчмаркинг. К нам пришел человек из конкурирующей компании, где делали то же самое. Мы детально поговорили и поняли, что у нас системы примерно одного порядка. А потом мы говорили про сроки. Я спросил, сколько времени они это писали, оказалось – 5 лет. А мы это сделали за 1,5 года. Это реальный пример. Получается ускорение в 3 с лишним раза по производительности. И это только за счет внедрения гибких методологий.

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

 

 

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

У меня был пример – мы запускали систему учета заявок. Ситуация стандартная: клиент накидывает заявки на доработку, ребята распределяют, все хорошо. Но примерно в 30% заявок мы не могли понять, что хочет клиент.

Все знают, как неспециалист пишет заявку. Он пишет, например: «Сделайте так, чтобы у меня тут быстрее обрабатывалось, а здесь выходило какое-то поле». Когда такое читаешь, то просто не понимаешь, о чем идет речь. А поскольку система конвейерная (быстрое производство с очень плотной загрузкой), то получалось, что такие задачи все время выпадали. И это было проблемой, потому что клиенты жаловались, спрашивали, почему одним сделали, а им нет. У них появлялось ощущение, что их специально игнорируют, не хотят заниматься их задачами. Недовольство клиента по этим задачам прилетало мне как руководителю, приходилось периодически ходить на ковер, объясняться, почему мы уже два месяца не можем сделать какую-то простую задачу. Было сложно объяснить, что заявку не берут в работу из-за того, что она плохо сформулирована. Это выглядело как будто «вы сами виноваты», получалось некрасиво.

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

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

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

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

 

Ключевые факторы успеха при внедрении гибкого управления

 

 

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

  • Принцип распределения ответственности. Очень часто есть такой риск: когда мы только начинаем внедрять гибкий подход, это всем нравится, всем интересно, глаза горят. Но как только начинается реальный проект, уже не до гибких методологий – руководитель по привычке распределяет, кому что делать, и система начинает сыпаться. Люди не понимают, почему вчера было гибко, вчера можно было выбирать, а сегодня тебя вызвали на ковер и принудительно дали задачу. Так делать нельзя. От этого система не взлетает. Это уже получится некий гибрид, который по производительности будет как иерархическая система.
  • Принцип открытости – когда информация открыта и доступна для всех участников. Иногда это сделать невозможно. У меня было два примера, когда из-за невозможности обеспечить открытость мы понимали, что гибкий подход внедрять не надо.
    • Первый – разработка сетевых анализаторов для госструктур. Весь проект был построен так, что программисты не знали, для чего они ведут разработку, у них было очень узкое функциональное ТЗ. Это было сделано специально – для безопасности, чтобы никто не понимал, как работает вся система в целом. От них был запрос как-то ускориться, добавить чего-то гибкого, чтобы программисты быстрее писали. Но когда мы стали анализировать, то поняли, что не сможем внедрить гибкий подход, потому что не работает принцип открытости. Поэтому они остались в обычной функциональной иерархии.
    • Второй пример – это корпоративный конфликт, когда две группировки внутри компании имели между собой много противоречий. Естественно, две эти группировки друг от друга информацию скрывали, и если на них попадал какой-то сквозной процесс (например, процесс снабжения), то они друг с другом информацией не делились. В таких условиях применять гибкие подходы тоже не получится, потому что в вопросах разрешения конфликтов гибкие методологии не помогают.
  • Еще один ключевой фактор, который дают гибкие системы – это снижение нагрузки на руководителя и расширение «узких мест», из-за того, что у нас появляется децентрализация.

 

Внедрение гибкого управления: циклы

 

 

Как внедряется гибкое управление?

Есть два методологических цикла – цикл планирования и цикл контроля исполнения.

Планирование делится на две итерации – в иерархии им соответствует планирование стратегической и тактической целей.

  • Длинную итерацию планирования мы делаем один раз в 3-6 месяцев – это так называемый «Большой круг», когда мы собираем всех людей, работающих на проекте, выполняющих какие-либо функции, и накидываем задачи. Например, одна наша ИТ-компания 1С-франчайзи для этого выезжала в пансионат, потому что нужно было собрать порядка 200 человек. Понятно, что если просто собрать вместе 200 человек, договориться о чем-либо нереально. Поэтому эти большие круги планирования были разбиты на три секции: продуктовую, по развитию рынков, по эффективности. На каждой секции обсуждались разные вопросы, потом они выносились на общее собрание, и в итоге у нас родился большой-большой стратегический план. Это очень похоже на обычные выездные мероприятия, но на них обязательно соблюдаются принципы, о которых я говорил:
    • К примеру, вопросы и задачи может включить любой человек – не только руководитель. Поэтому списки задач порой получаются очень большие – по 300-400 пунктов.
    • Самое главное – никто никого не ограничивает. Если программист, например, предложил поменять платформу, то даже если мы понимаем, что это неадекватная задача, мы ее все равно записываем. Не факт, что мы это сделаем, но мы ее фиксируем и тем самым разрешаем говорить все, что угодно. Такая ситуация иногда напрягает. В некоторых командах на совещаниях могут начать обсуждать холодильник в офис или теннисный стол. Но, как я уже говорил, бояться этого не надо, потому что примерно 70% задач, которые люди накидали, в работу потом не пойдут. И ничего страшного нет в том, что у нас какие-то гигантские списки задач, и непонятно, кто эти вещи будет делать.
  • Когда мы выбрали задачи, мы делаем короткую итерацию. Это производственный этап. Он может длиться месяц-два – это оптимальный период (если слишком длинная динамика, мы забываем, что запланировали, а если слишком короткая, то не успеваем сделать все намеченное). В короткую итерацию мы нарезали задач, накидали, какие именно задачи будем выполнять, люди сами определились, кто какую задачу берет, кто что будет делать. Единственный минус: в отличие от иерархии в итерации нельзя скинуть с себя задачу, нельзя сказать, что не успеваешь, и отдать задачу другому. Потому что плывет вся система, пропадает фактор давления, пропадает плановая четкость, пошаговость. Вот такой небольшой недостаток. Но с учетом выигрышей, которые дает гибкий подход, он нивелируется.
    • Прошла первая короткая итерация, у нас появились какие-то результаты – что-то сделано, что-то не сделано.
    • Начинается новая итерация – в нее мы берем следующие задачи и те, которые остались с предыдущей итерации.
    • Такие короткие итерации мы делаем несколько раз в течение 3-6 месяцев, а затем мы снова собираемся большим кругом, смотрим, куда идем.
  • Аналог стратегического планирования в гибкой методологии – это выделение фокуса стратегических задач. Внутри компании есть малый управленческий круг – небольшой экспертный совет из 3-6 человек, определяющих вектор развития. Они смотрят на задачи и отмечают, что для них действительно важно. Например, для компании-франчайзи было важно увеличить прибыль и увеличить выручку за счет выхода на новые рынки – это был стратегический фокус компании. Это не цель, как в иерархии, которой надо добиться любой ценой. Это стратегический фокус – руководство компании хотело бы выйти на новые рынки. Т.е. выделяется набор задач, соответствующих этой стратегической цели, и эти задачи особым образом помечаются, чтобы люди, когда берут такие задачи в работу, понимали, что помогают в продвижении стратегической цели.
  • Распределение задач. Есть два механизма, как распределяются задачи.
    • Первый – задачи распределяются через голосование. Представьте, у нас большой открытый список, в котором люди себе выбирают задачи. Но часто бывает конкуренция: одну и ту же задачу могут выбрать несколько человек. Поэтому есть арбитр в лице малого круга, который распределяет задачи, но договорным способом, без назначений, без конфликтов.
    • Второй механизм – корректировка распределения задач. Он удобен, чтобы разрешить конфликт, а также для распределения подвисших задач. Например, осталось несколько важных задач, а их никто не взял. Тогда члены малого круга предлагают их разобрать. В качестве примера я уже рассказывал, как у нас была построена разработка. У нас было порядка 9 программистов и 2 руководителя – один занимался текущей техподдержкой, второй – разработкой. Все задачи скидывались в общую систему, перед началом итерации один день уделялся планированию – ребята отмечали, кто какую задачу возьмет. Потом руководители смотрели, все ли охвачено, нет ли чего-то важного, что мы забыли или не успели сделать в прошлый раз. Если такие задачи оставались, ребят просили их разобрать.

 

 

Что касается контроля исполнения, то в процессе это выглядит так:

  • Мы собираем статусы по задачам: интересуемся, как обстоят дела у исполнителей, не нужна ли им помощь. Это все устно – подробных отчетов писать не нужно, и нет никакого наказания, если человек скажет, что что-то не успевает сделать.
  • Затем мы подводим итоги итерации, смотрим, что сделали.
  • Далее начинается следующее распределение задач.

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

  • Большой круг у нас длился 2 дня, мы накидали список задач.
  • Еще 2 дня мы этот список структурировали в удобном виде.
  • Дальше просто все распределили и приступили к работе.

Представляете, какой это выигрыш!

 

Где гибкое управление работает

 

 

По моему опыту гибкое управление работает в следующих сферах:

  1. Разработка и сопровождение 1С, отдел разработки. Я про это рассказывал: когда есть пул задач – люди выбирают, чем займутся, мы следим, чтобы все важные задачи были приняты. Гибкое управление в этом помогает.
  2. В группе компаний, проектный отдел. Это кейс с выездом 200 человек – там изначально была задача переформировать проектную организацию в продуктовую. Изначально у нас это не получалось, хотя все осознавали важность задачи – были установлены сроки, назначены ответственные, но почему-то организационно процесс не шел. Гибкие методологии ситуацию изменили.
  3. Поставка инженерных систем, дистрибуция, торговля железом. Здесь тоже достаточно хорошо работает.
  4. Про внедрение 1С еще один кейс был – там тоже гибкое управление помогло.
  5. Еще один интересный кейс, когда выводили ИТ-компанию из группы в отдельный самостоятельный бизнес. Изначально был внутренний ИТ-отдел, который обслуживал холдинг, и решили, что он должен начать зарабатывать. Но что бы они ни делали, ничего не получалось. Гибкое управление помогло.

 

Частые вопросы

 

 

Коротко рассмотрим несколько самых частых вопросов.

  1. Как меняется зарплата и премия при внедрении гибкого подхода? Никак. Это вообще не влияет. Когда мы внедряем гибкие методологии, производительность растет всегда независимо от системы финансовой мотивации, которая уже в компании работает. Я внедрял гибкие методологии и в жестких иерархических структурах, где зарплату невозможно выбить (сколько дали – столько дали), и в компаниях, где люди были мотивированы от прибыли. В обоих случаях при внедрении производительность повышается.
  2. Когда нельзя внедрять гибкое управление? Я уже рассказывал об этом: когда невозможно внедрить хотя бы один из протоколов – открытость, распределение ответственности или командную работу.
  3. Можно ли внедрять в группе, в отделе, в департаменте, если вся компания иерархическая? Можно, это нормально живет. Но наоборот не работает: если вся компания гибкая, что-то иерархическое там не выживает. Но это, скорее, книжный кейс, в жизни такого я не видел. Чаще всего это крупные компании, где какой-то отдел, направление или функция перестраиваются на гибкие методологии.

 

Вопросы

 

  • Хочу уточнить по поводу распределения ответственности. У меня возникает диссонанс: если мы распределяем ответственность, я предполагаю, что это может отразиться и на зарплате, но на зарплате это никак не отражается. Если это не отражается на зарплате, то это уже демотивирует, причем очень сильно. Или там как-то по-другому ответственностью распределяется?
  • Это очень частый вопрос: ответственность распределили, а денег нет. Но тут ответственность в большей степени психологическая, поэтому мы ее от денег свободно отрываем. Когда вы начинаете это пробовать, внедрять, вы видите, что хуже никому не стало, люди мотивируются, у них появляется больше выбора, они выбирают, чем позаниматься, не надо спрашивать ни у кого разрешения. Это сильно мотивирует. А если кто-то спрашивает про зарплату, мы говорим, что здесь действует определенный протокол, в нем есть конкретные правила, и все нормально работает.
  • Когда в отдел поступает куча задач от разных департаментов, может сформироваться пул, на выполнение которого потребуется больше 1-2 месяцев. Но заказчики хотят знать конкретные сроки, когда будет сделана каждая задача. Как им ответить?
  • Мы в одном из проектов сделали обычный лист ожидания, и в нем были плановые сроки. Но неприятность была в том, что они сдвигались, если в течение итерации мы не успевали.
  • Если каждый выбирает то, что ему нравится, то как нам двигать вперед критические проекты?
  • Обычно задачи, которые человек выбирает добровольно, делаются быстро. Производительность растёт.
  • А если все сломалось, упало, и надо прямо сейчас чинить?
  • Внедрение гибких методологий не отменяет обычных процессов поддержки. Наверняка есть кто-то, кто за это отвечает, в чьей это компетенции. Это же не совсем творчество типа «хочешь – ходи на работу, хочешь – не ходи». У нас есть точно такие же процессы, которые надо поддерживать. Но если человек этим занимается, он это добровольно выбирает. Мы исходим из этого.  

 

****************

Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2019. Больше статей можно прочитать здесь.

Приглашаем всех принять участие в тематических митапах Инфостарта: infostart.ru/events/

Специальные предложения

Оставьте свое сообщение

См. также

Стыд и Скрам: взгляд глазами собственника из IT-шников

Управление проектом Agile (XP, SCRUM, Канбан) 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

Не все, кто употребляют понятия Agile и Scrum, понимают, что они означают. О том, насколько в реальном мире автоматизации бизнеса на платформе 1С применимы гибкие подходы к разработке ИТ-продуктов на конференции Infostart Event 2019 рассказал основатель и соучредитель группы компаний WiseAdvice Иван Тягунов.

18.09.2020    2492    IvanAT1981    2    

Кому и зачем нужна автоматизация? Кто и как ее должен делать?

Автоматизация ИТ-компании Управление проектом Бесплатно (free)

1С-никам не надо объяснять, что такое автоматизация. Но они редко задаются вопросом «кому и зачем она нужна». Хотя, понимая эти моменты, не только проще выполнять свою работу, но и удобнее взаимодействовать с заказчиками. Об этом на конференции Infostart Event 2019 Inception рассказал индивидуальный предприниматель Юрий Бухонин.

31.08.2020    1676    sver_y    2    

Интеграция с Трелло. Готовый код

Обмен данными 1С Интеграция Agile (XP, SCRUM, Канбан) v8 Бесплатно (free)

Код основных действий, интеграция с API Трелло.

19.08.2020    2759    Yashazz    14    

Статья о системе маркировки

Автоматизация ИТ-компании ИТ-компания Россия Бесплатно (free)

В этом году вышло сразу несколько статей о практике работы с новой системой маркировки “Честный знак”. Написаны они “айтишниками” IT-отделов компаний-участников оборота, что отражает их взгляд на ход пилотного проекта и первые дни запуска боевой системы. Систему часто критиковали и критикуют, в основном из-за частых изменений API, багов личного кабинета и белых пятен в некоторых процессах. Мы решили, пусть и не первыми, опубликовать свой опыт и свои мысли об этом новом амбициозном проекте государства, в котором мы активно участвуем.

03.08.2020    2378    Cleverence    30    

И еще раз об "аутстаффинге" в 1С

Управление проектом Автоматизация ИТ-компании Бесплатно (free)

В ранее вышедшей статье «"Аутстаффинг" на проектах 1С - слово страшное, но симпатичное» была описана эффективная формой привлечения 1С-специалистов: "аутстаффинг" (лизинг персонала). С полным текстом исходной статьи можно ознакомиться тут: https://infostart.ru/public/1181532/ В данном очерке автор попытается несколько углубить описание «аутстаффинга», и более детально описать его возможное применение на проектах внедрения 1С, приведя примеры из собственной практики.

30.07.2020    1598    Богатырев Артур    2    

Как эффективно управлять командой удаленных программистов 1С

Автоматизация ИТ-компании УУ Бесплатно (free)

Дистанционная работа становится все популярнее, и многие компании задумываются о том, что, возможно, стоит попробовать работать с разработчиками на удаленке. Но чтобы такое сотрудничество было эффективным, придется не только контролировать код на выходе. Нужно еще научиться взаимодействовать в условиях разных часовых поясов, вести учет отработанного времени, уметь удержать и заинтересовать работника. О том, как эффективно управлять удаленной командой высококвалифицированных программистов 1С, на конференции Infostart Event 2019 Inception рассказал руководитель компании «Крон» Ранис Усманов.

27.07.2020    8343    Ranis1286    45    

Придет владелец продукта и решит все вопросы бизнеса!

Agile (XP, SCRUM, Канбан) Бесплатно (free)

Практически во всех крупных проектах есть отдельная роль – владелец продукта. Все чаще ее выполняют аналитик либо представители бизнеса, но насколько эффективно они работают, мало, кто задумывается. О том, что должен делать Product Owner, и какие ошибки чаще всего совершают такие специалисты, на конференции Infostart Event 2019 Inception рассказал управляющий партнер и Agile Coach компании Scrumtrek Иван Селеверстов.

24.07.2020    2521    iseleverstov    0    

Как "сказка о репке" влияет на управление ИТ

Автоматизация ИТ-компании Бесплатно (free)

Почему российские руководители не готовятся к кризису заранее, а ждут, когда жареный петух клюнет? Почему в кризис отечественный бизнес совершает подвиги, а в мирное время – застаивается? Почему сотрудники в «военный период» самоорганизуются и выполняют такие задачи, за которых в спокойный – даже браться боятся? На все эти вопросы в своем докладе на конференции INFOSTART EVENT 2019 Inception ответил директор по информационным технологиям ГК «МОСТ-1» Роман Троупянский.

13.07.2020    3442    useresu    3    

Почему Scrum не работает в проектах 1С

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

Более точная формулировка заголовка, пожалуй будет такой -  Почему Scrum в чистом виде плохо работает в проектах внедрения продуктов 1С.

18.05.2020    11035    MariaTemchina    33    

Замеры APDEX против "ощущений" бухгалтеров

Автоматизация ИТ-компании Бесплатно (free)

Очень часто пользователи недовольны, как работает информационная система. Но даже когда ИТ-специалисты все полностью меняют, пользователи остаются недовольными. О том, как объективно оценить проведенные изменения, на конференции Infostart Event 2019 Inception рассказал руководитель ИТ-службы ИООО «Лукойл Белоруссия» Роман Жульпо.

24.04.2020    4272    it-boy    19    

Где взять программистов, если вы не Google или Яндекс, и ваш офис расположен не в Москве?

Автоматизация ИТ-компании Бесплатно (free)

Многие отечественные компании сталкиваются с нехваткой квалифицированных кадров, особенно если расположены в небольших городах. Вузы специалистов не готовят, отбирать у конкурентов – дорого, приглашать из столиц – еще дороже, да и никто не согласится. Как же быть? Об одном из решений проблемы подготовки специалистов рассказал на конференции IT-директор компании «ДНС Ритейл» Андрей Гончарук.

30.03.2020    3621    Goncharuk.a    10    

Визуализация фич Vanessa Automation в StoryMapper

Agile (XP, SCRUM, Канбан) Сценарное тестирование Vanessa Automation ИТ-компания 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

Описан процесс визуального упорядочивания коллекции feature-файлов в виде карты пользовательских историй. Используется инструмент гибкого управления требованиями StoryMapper.

21.03.2020    3069    oleynik.dv    7    

От стажера до эксперта: развиваем команду разработчиков

Автоматизация ИТ-компании Бесплатно (free)

Большинство руководителей компаний понимают, что сотрудников надо обучать и развивать, но как это делать, плохо себе представляют. Как организован процесс обучения и развития разработчиков 1С в компании ФТО, на конференции Infostart Event 2019 Inception рассказал Виталий Онянов.

20.03.2020    6474    Tavalik    17    

Программные роботы и реальная польза от RPA. Живые кейсы

Автоматизация ИТ-компании Россия Бесплатно (free)

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

06.12.2019    5737    bolefirenko    55    

Эмоциональный интеллект в управлении ИТ-командами

Управление персоналом (HRM) Автоматизация ИТ-компании Бесплатно (free)

Эмоциональный интеллект, как явление и направление, начали изучать сравнительно недавно – около 30 лет назад. Но за это время появилось уже немало знаний, которые можно и нужно использовать в управлении ИТ-командами. Как это сделать, участникам конференции рассказала консультант студии креативного консалтинга «Не просто ИДЕЯ» Ирина Шишкина.

18.11.2019    3946    user596192_shiiisha    7    

История роста и работы команд 1С в условиях HighLoad и BigData

Автоматизация ИТ-компании Производительность и оптимизация (HighLoad) Бесплатно (free)

Современные потребности бизнеса заставляют программистов 1С решать все более сложные задачи. А главные требования, которым необходимо соответствовать, – вовремя поставлять ценности высокого качества. С какими сложностями приходится сталкиваться в работе программистам в динамично развивающейся брокерской сфере, и как их решают, на конференции Infostart Event 2018 Education рассказал начальник отдела интеграции БКС Технологии Сергей Артемов.

11.11.2019    7797    user826155    11    

Agile в проектах 1С: где-то между невозможно и неизбежно. Часть вторая

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

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

06.09.2019    6170    MariaTemchina    10    

Agile в ИТ-проектах: где-то между невозможно и неизбежно

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

Приглашаем к дискуссии по мотивам прошедшего вебинара на тему "Agile и не Agile"

15.08.2019    6969    MariaTemchina    40    

Scrum: серебряной пули не существует

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

Гибкие методологии набирают популярность среди команд разработчиков. Но применять их в том варианте, который предлагается первоначально, не всегда удается. О своем опыте работы по Scrum в условиях, когда нет проектов, рассказал на конференции Infostart Event 2018 Education ведущий разработчик 1С одной из крупнейших торговых сетей Дмитрий Кирилкин.

12.08.2019    5456    dumsik    7    

Стыд и Скрам, часть вторая

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

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

14.03.2019    11698    MariaTemchina    47    

Стыд и скрам - Чему нас учит Scream Guide

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

Название "Scream Guide" можно вольно перевести на русский как “Вопль ужаса от того, как Scrum применяют на практике”

12.02.2019    10227    MariaTemchina    20    

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

Управление проектом Waterflow Итеративный подход Agile (XP, SCRUM, Канбан) Бесплатно (free)

В своем докладе Мария Темчина подробно рассказала про то, какие подходы к управлению проектами вообще бывают с точки зрения Project Management Institute, и какие из них применимы при руководстве проектами внедрения 1С.

21.01.2019    8033    MariaTemchina    0    

Черная книга Скрам

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

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

26.11.2018    8433    Selikhovkin    4    

[Заметки] Scrum за 5 минут

Agile (XP, SCRUM, Канбан) Бесплатно (free)

Первый опыт создания статьи в сообществе. Немного о Scrum и нашем знакомстве.

20.11.2018    8848    leobrn    11    

Думать некогда, трясти надо - или что такое ретроспектива в Agile

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

12-ый принцип Agile-манифеста, как известно, гласит: "Каждый раз в конце заранее определенного интервала времени команда размышляет, как повысить результативность своей работы, и затем вносит коррективы в процессы." Попробуем разобраться, как это стоит, а как не стоит делать на практике. 

13.11.2018    10431    MariaTemchina    16    

Приоритизировали, приоритизировали, да не выприоритизировали...

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

В ответ на классическое требование "сделать всё и сразу" Agile предлагает "сделать сразу, но не всё". В этой статье я хочу поговорить о разных методах приоритизации требований.

30.10.2018    8471    MariaTemchina    47    

Построение высокоэффективной Agile-команды

Управление проектом Управление командой Agile (XP, SCRUM, Канбан) Бесплатно (free)

Меня зовут Асхат Уразбаев, я из компании ScrumTrek. Наша компания помогает внедрять Agile, Scrum, Kanban – гибкие методологии и гибкие подходы. К миру 1С я совсем не принадлежу, но в прошлом я, тем не менее, программист – занимался разработкой на самых разных языках программирования. Помимо основной деятельности у меня было несколько технологических стартапов, в которые я был так или иначе вовлечен. И сегодня мы поговорим о том, как сделать так, чтобы команда была крутой и эффективной.

08.10.2018    7770    askhatu    15    

Канбан в условиях российской действительности

Управление бизнес-процессами (BPM) Управление проектом Agile (XP, SCRUM, Канбан) Россия Бесплатно (free)

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

08.08.2018    23840    MariaTemchina    64    

Почему Agile превращается в Тяп-ляп. Кто виноват и что делать?

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

В моей практике довольно много историй, когда компании, решившие внедрять гибкие методологии, начинали за здравие (Agile), а кончали за упокой - Do & Fix (делаем, как бог на душу положит). Попробуем разобраться, почему так происходит.

27.07.2018    13259    MariaTemchina    20    

Можно ли объять необъятное или чем Agile отличается от водопада?

Управление проектом Waterflow Agile (XP, SCRUM, Канбан) Бесплатно (free)

Что общего между управлением парусной яхтой и проектом по внедрению ERP-системы на предприятии? В данной статье я постаралась понятным языком описать разные подходы к проектному управлению, и разобраться при каких условиях та или иная методология может быть полезной при реализации проектов.

23.07.2018    12708    MariaTemchina    42    

Применение Agile-технологий в проектах 1С

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

Agile – это одна из методик ведения проектов. О ее практическом применении в проектах 1С пойдет речь в статье.

25.07.2017    18191    kondrat230386    35    

Agile для внутренней разработки

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

Речь пойдет о том, что такое гибкие методологии. Статья написана на основе доклада, прочитанного на Конференции IE 2013 Revolution (7-8 ноября 2013 года).

29.09.2015    15460    askhatu    14