Как работать по аджайлу. Часть 3: «Что значит „по аджайлу“»

Как работать по аджайлу. Часть 3: «Что значит „по аджайлу“»

Алексей Проворов

В предыдущих сериях

В первой части мы выяснили, с какими проблемами сталкиваются сейчас продукты:

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

Во второй части прикинули, что бы случилось если бы мы вдруг захотели делать продукт «по-старинке». Собираем требования, делаем сайт, запускаем рекламу.

Мы представили, что делаем приложение по доставке шавермы. Полгода потратили на разработку, а потом «Деливери-клаб» стал доставлять шавермы и мы поняли, что нет смысла развиваться.

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

В 2001 году придумали Аджайл-манифест. Это документ, в котором закрепили 4 ценности и 12 принципов управления проектами. Ценности определяют образ мышления, принципы — помогают в них разобраться:

  1. Люди и взаимодействие важнее процессов и инструментов;
  2. Работающий продукт важнее исчерпывающей документации;
  3. Сотрудничество с заказчиком важнее согласования условий контракта;
  4. Готовность к изменениям важнее следования первоначальному плану.

Аджайл не отрицает важность того, что справа, но больше ценит то, что слева.

Люди и взаимодействие важнее процессов и инструментов

Люди — все, кто участвует в создании и потреблении продукта. Заказчик, менеджер, разработчик, знакомый юрист, друг, которому показали ссылку, будущие клиенты. Взаимодействие — общение людей голосом, в скайпе, в чатике, по почте, в коментах Гугл-дока.

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

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

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

Если бы дизайнер заранее показал набросок, осталось бы время на проработку стиля. Положил бы в портфолио крутую работу, а не безликий макет:

Дизайнер собирает замечания по макету на встрече с командой

Работающий продукт важнее исчерпывающей документации

Работающий продукт приносит деньги. Шаверма — работающий продукт, а концепт карты с курьерами, который нарисовал дизайнер, — неработающий. Картинками не наешься.

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

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

Если бы мы поговорили с дизайнером сразу, то не пришлось бы полтора месяца переписывать техническое задание, потому что там были лишние функции:

Дизайнер сразу обсуждает задачу с заказчиком, а не просит ТЗ

Сотрудничество с заказчиком важнее согласования условий контракта

Сотрудничество с заказчиком — про партнёрские отношения, а не «я начальник — ты дурак». Заказчик — такой же участник процесса. Он лучше знает продукт и клиентов, но может не знает особенностей разработки.

Согласование условий контракта — когда команда не может ни на шаг отступить от ТЗ, потому что «ну мы для кого это всё писали» и «это уже согласовано с генеральным».

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

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

Если бы мы написали в «Топ Донер», они бы поделились базой точек с шавермой. Не пришлось бы вбивать адреса базу вручную и тратить время попытки её скопировать. А вдруг ребятам бы так понравился проект, что они бы рассказали о нём в паблике на на 35 тысяч человек.

Строчка в договоре может спасти директора от тюрьмы, но когда с заказчиком дружат, проблемы решают в баре, а не в суде:

Юрист вносит изменения в оферту по просьбе разработчика

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

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

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

Когда Деливери-клаб добавил точку с шавермой к списку ресторанов, мы опустили руки и отказались от проекта. А что если нашим преимуществом мог быть большой ассортимент. Мы бы нашли общий язык с Джамалом с Думской, Ахметом из Девяткина и Серёгой из Купчина.

Голодным клиентам бы привозили шаверму за 15 минут, потому что знаем ларёк рядом с домом. Гурманам — привозили бы шаверму с гранатовым соусом через весь город, потому что знаем, где такую готовят:

Мы справились с трудностями и теперь обучаем франчайзи из 35 городов России

В итоге

Важен результат, а не процесс. Чтобы получать результат быстрее, больше общайтесь, ошибайтесь, пробуйте новое и не опускайте руки.

Часть 4: «Для каких задач подходит аджайл»

http://telegra.ph/agile-03-19

Чтобы не пропустить, подписывайтесь на канал @korobkame в Телеграме.

Report Page