Как мы в Atlas Software понимаем Agile. С чем мы согласны и с чем совсем нет

Пояснение: Мы разработчики системы автоматизации управления бизнес-процессами ATLAS BPM. Уникальной системы, которая сочетает глубокие профессиональные модули, такие как BPM, CRM, HRM, WMS и MES с современными облачными технологиями и дружественным интерфейсом.

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

Но следуем ли мы этим принципам слепо? Нет и еще раз нет.

Я расскажу как мы осознали Agile, как и чему мы следуем, а чему нет.

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

Не забывайте, Agile — это не методология, это набор ценностей, если хотите, мировоззрение.

Поэтому невозможно изучить Agile. Или он есть в вас и вашей команде, или же его нет.

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

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

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

Как мы читаем этот принцип: Наивысшим приоритетом для нас является удовлетворение БУДУЩИХ потребностей заказчика.

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

Это рискованно? Конечно. Но только так мы и будем действовать.

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

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

. Декарт сказал : “ Я сомневаюсь значит я мыслю. Я мыслю, значит я существую”. Мы сомневаемся всегда, и задаём себе вопрос: повысило ли вашу конкурентоспособность наше обновление?

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

В этом смысле, Декарта можно считать сооснователем Agile :)

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

3 Принцип: Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.

Устаревший принцип. Работающий продукт нужно выпускать каждый день. Точка.

И даже не спорьте.

4 принцип: На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.

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

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

Но! Этого мало. В нашем продукте изначально заложены инструменты сбора обратной связи. И мы ее получаем каждый день. Ни одна идея или обращение не проходит мимо разработчиков. Иногда это утомительно. Разбирать идеи клиентов дело муторное. Но мы с первых дней сделали это частью нашей жизни.

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

5 принцип: Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.

Ох какой важный и многофакторный принцип.

Мотивированные

Самое тонкое место для вас, когда вы начнете внедрять Agile. До сих пор большинство менеджеров просто не понимают как работает мотивация. Система мотивации это не система оплаты. Мотивацию рождает сложная синергия ценностей компании с ценностями сотрудников. Это основа мотивации. По мотивации можно и нужно писать трактаты. Не формат этой статьи написать все что можно про мотивацию.

Постарайтесь запомнить одну простую формулу мотивации персонала.

Мотивированный сотрудник = высокая осмысленность работы + синергия личных и реальных (а не декларируемых) ценностей компании + наличие вокруг, в одной команде, близких по ценностям и профессионализму людей + сложные задачи + разумная организация труда.

Простая? Я вру. Формула не простая. Сразу бросьте внедрение Agile, если не следуете этой формуле или как-то по другому понимаете мотивацию.

Профессионалы

Вы думаете профессионал по Agile этот тот, кто обладает хорошими навыками и компетенциями?

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

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

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

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

Agile-профессионал для нас — это труба, а не сосуд. Тот, кто пропускает через себя много знаний, а не собирает их.

Создайте условия

Все думают, что условия — это картинка Google офиса: панорамные окна, диваны, кофе и прочий антураж.

Да это не плохо. Но где выше, в принципах, что-то есть про диваны? О чем я писал? О том, что такое “профессионал”.

Так вот — создайте условия для обеспечения роста профессионализма. Дайте время на обучение. Мотивируйте на это. Дайте вектор для развития. Ставьте сложные задачи. Ставьте нереально сложные задачи.

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

Доверьтесь им

Да разве вы умеете доверять своим сотрудникам? Если нет ценности доверия в компании, о каком Agile может идти речь?

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

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

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

6 принцип: Непосредственное общение, является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.

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

У нас в отделе разработки сейчас 8 человек. Все, слышите, все, находятся в разных городах.

Для нас непосредственное общение — это общение без посредников и концентрированная коммуникационная среда.

Чем распределеннее команда, тем концентрированнее должны быть коммуникации. Это достигается благодаря облачным средствам автоматизации, которые мы используем. ATLAS BPM этому помогает.

7 принцип: Работающий продукт — основной показатель прогресса.

Некоторые думают, основной,— значит единственный.

Работающий продукт — это показатель результативности. Без показателей усилий, вы не сможете быть эффективными.

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

По процессу разработки мы замеряем 11 показателей. И это мы еще ленимся.

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

8 принцип: Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.

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

Иногда сочетать разные принципы Agile не просто. Ищите свой путь и свою комбинацию. Ритм очень важен.

Пугает как-то понятие “бесконечно”? Не знаю. Мы слишком молоды, чтобы рассуждать о бесконечности :)

9 принцип: Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.

Я бы расширил формулировку : “Внимание к совершенству проектирования и постановке задач — единственный путь к техническому и пользовательскому совершенству.”

В качестве проектирования в целом, и постановке задач в частности, заложено 90% производительности вашей команды. На это завязано все, даже мотивация.

Не умеете ставить задачи, даже не пытайтесь внедрять Agile.

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

Задачи нужно дробить максимально и формулировать максимально подробно. Начинать всегда необходимо с разъяснения, для чего это нужно клиентам. Потом, к чему это может привести продукт в будущем, как это затронет архитектуру, как это повлияет на производительность, на удобство. И только потом, подробно, с рисунками, если нужно, описывать задачу.

10 принцип: Простота — искусство минимизации лишней работы — крайне необходима.

Настоящая простота спрятана в сложности. Хотите простоты? Идите к ней сложной дорогой.

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

Хотите простоты для пользователя, готовьтесь к войне с функциональностью. На линии боя будет ваш продукт.

11 принцип: Самые лучшие требования, архитектурные и технические решения, рождаются у самоорганизующихся команд.

Самоорганизующаяся команда — это мечта и цель. Стремиться к ней нужно всегда. Но в такой команде не рождаются лучшие решения на автомате.

Я бы сказал, что в хорошей команде повышается вероятность появления лучших решений.

Одиннадцатый принцип нас как бы направляет: “эй, чуваки, стройте самоорганизующиеся команды!” Agile направляет в эту сторону, но не дает ответа, как туда дойти. Об этом говорит современный научный менеджмент.

А если вы не считаете научный менеджмент фокусом вашего профессионализма, если вы рассчитывали, что прочитаете 12 принципов или пройдете Agile-тренинг и станете жить по Agile, то вы жестоко ошибаетесь.

См. 10 принцип: Настоящая простота спрятана в сложности. Хотите простоты? Идите к ней сложной дорогой.

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

Очень хитро — самое вкусное оставили на конец и написали очень кратко.

Авторы “12 приниципов” как бы спрятали большой секрет в маленькой коробочке под названием “Манифест Agile”. Они как бы приоткрыли завесу миру, но самое важное утаили для узкого круга.

В этом приниципе спрятана огромная глыба, именуемая “научный подход к менеджменту”. Тут у нас и Деминг и Шухарт, Голдратт и Канеман. А глубже: статистическое управление процессами и идеология компании, процессное управление и еще куча всего...

Все 11 принципов разрушатся без глубокого понимания двенадцатого.

Систематически анализировать способы улучшения эффективности. Каково?

Как это делаем мы? С помощью двух методологий и нескольких систем автоматизации.

Мы обьединили SCRUM с процессным управлением. Это позволило смоделировать и автоматизировать процесс разработки. Для этого мы собираем кучу показателей, строим по ним диаграммы Шухарта. Анализируем показатели и формируем гипотезы по их улучшению. Запускаем гипотезы, смотрим как изменились показатели и меняем процесс.

Это я так кратко описал глубокую управленческую работу.

Заключение

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