Сергей Кравцов, сооснователь Evergreen

Мы занимаемся IT-разработкой. И как любая проектная организация, сначала пробовали использовать каскадную модель управления (в отрасли ее называют waterfall). Принцип этой модели известен всем: обозначил конечный результат, разбил на этапы, запланировал, забюджетировал, сделал. Однако по ряду причин она не устраивала ни меня лично, ни нашу компанию.

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

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

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

Сегодня 95% клиентских проектов мы выполняем с использованием смешанного подхода: общий каркас остался от waterfall — фиксированные цены каждого этапа, диаграммы Гантта, а от Agile берем то, что помогает справляться с неопределенностью. Например, самые сложные и непонятные куски проекта выполняем мелкими итерациями и в самом его начале. Чистую же Agile мы применяем в своих продуктах и процессах.

Agile методология позволила быстрее принимать реальность, реагировать на изменения и выстраивать процессы

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

Например, мы разработали софт, который распознает техпаспорта авто, загранпаспорта по фотографии за несколько секунд, и сейчас его продаем. Как это было? Сначала родилась идея: нужен такой софт, чтобы клиент мог оформлять страховку не за семь минут, как сейчас, а просто сфотографировав документы и сделав два-три клика. Мы прошлись по клиентам, узнали, кому это интересно, посчитали, сколько стоит разработка. Разделили цену разработки на количество готовых купить, получили приблизительную цену за одну лицензию. Подумали: сработает или не сработает? Пришли к выводу, что продавать за такие деньги реально. Результат непонятен, поскольку такого никто не делал. Есть отдаленно похожие аналоги, но они имеют существенные ограничения, поскольку технология для Украины новая.

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

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

Agile не должна становиться синонимом безответственности, но очень часто им становится из-за неправильного использования принципов гибкого подхода

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

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

Как ее выявить? У нас есть правило: самых высокооплачиваемых специалистов мы берем с испытательным сроком три дня, средних — неделя. Почему так? На эти три дня или неделю человеку дают задачи и погружают в процессы без объяснения, как они работают. За три дня трудно что-то испортить, но можно полностью проявиться. Для руководителя такой подход — возможность посмотреть, как человек работает самостоятельно.

У нас ответственность за понимание задачи лежит на том, кому она ставится

У нас ответственность за понимание задачи лежит на том, кому она ставится. Вот пример диалога с исполнителем:

— Мне тут нужно построить стену.

— Окей!

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

Что делать руководителю в таком случае? Можно попросить прокомментировать решение, объяснить, как себя вести в будущем, как выяснять детали задачи и критерии принятия решения.

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

Как организовано рабочее время? У нас нет графика с 9 до 18, обязанности работать в офисе. У нас в принципе нет многих ограничений, стандартных для других компаний. Есть результат, над которым мы работаем. И если он не достигается — не важно, что ты вовремя приходишь или не ходишь на перекуры. Чтобы понимать, когда должна быть выполнена та или иная задача, используются недельные спринты, которые составляются с учетом более высокоуровневого планирования типа графиков проектов или стратегии развития.

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

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

Легко ли найти подходящих сотрудников и как мы их отбираем? Кандидатов найти сравнительно легко, хотя процесс отбора непростой. Например, нужен человек, который умеет администрировать серверы, ты выходишь на рынок, выбираешь по резюме. Есть система вопросов-фильтров, чтобы отбирать тех, кто показался: а) профессиональным; б) с соответствующими ценностями. Зовешь их на интервью, отсеиваешь еще раз — на этот раз более серьезно, исходя из профессиональных навыков и, что не менее важно, на предмет того, впишется кандидат в команду или нет. По итогу оставляешь тех, кто профессионален и впишется. Команда не жесткая и процент тех, кто впишется, довольно большой. Поэтому мы стараемся максимально спрогнозировать, как поведет себя человек в важных рабочих ситуациях, и задавать ему поведенческие вопросы прямо на интервью. Тех, кто прошел, берем на тестовые три дня или неделю. И дальше смотрим, какой результат они за это время покажут.

Например, один кандидат очень хорошо проявил себя в тестовом задании, классно провел интервью, но в процессе работы ни одну задачу выполнить не мог, вопросов практически не задавал. На вопросы «Что ты делаешь? Почему ты решил, что нужно делать это?» отвечал: «Вот я так решил, не знаю почему». В подобных случаях быстро становится понятно, что дела не будет, и достаточно быстро человека отпускаешь искать компанию, которая ему больше подходит.

Для Agile-команды не должно быть понятия «ты не можешь этого делать, это не твоя компетенция». Если справляешься со своей работой хорошо и хочешь больше — бери

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

В целом я считаю, что для Agile-команды не должно быть понятия «ты не можешь этого делать, это не твоя компетенция». Если справляешься со своей работой хорошо и хочешь больше — бери. Еще очень важная особенность нашей корпоративной культуры — прямота и открытость. Например, РМ’ы ежедневно пишут обратную связь на C-level (CEO, COO, CTO) и могут там сказать о своих идеях, опасениях, сомнениях — и знают, что им быстро ответят.

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

мы — команда наемных предпринимателей

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

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

ОСТАВЬТЕ ОТВЕТ

Please enter your comment!
Please enter your name here

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.