Аннотация
- Докладчики
Что будет, если практики Agile распространить не только на разработчиков, но и на всю команду — на аналитиков, проектировщиков интерфейсов, документаторов, продвиженцев? Как поменяется работа аналитиков? Сколько времени потратить на начальные исследования пользователей? Когда уже можно начинать программировать? Можно ли проектировать интерфейс по кускам? Как составить ТЗ, чтобы его прочитали разработчики?
В докладе мы ответим на эти и подобные вопросы, основываясь на нашем опыте, полученном в проекте «Электронный бухгалтер Эльба».
Видео
Видео в HD-качестве, смотрите в полноэкранном режиме.
HTML-код включения <iframe src="http://player.vimeo.com/video/23323542?byline=0&portrait=0" width="720" height="405" frameborder="0"></iframe>
Для этого доклада нужен подкаст (аудиозапись)?
Презентация
Примечания и отзывы
Сначала там выступали ребята из Эльбы с докладом про то, как они организовали работу по Agile в своей компании. Причем сделали это не только для разработчиков, но и для остальных ролей, включая аналитиков, внедренцев, проектировщиков интерфейса и прочих. Ребята рассказывали очень живо, было много шуток и веселых слайдов. После обеда они однозначно не дали аудитории уснуть.
©
Интересно узнать, что у нас есть прям молодые продуктовые команды, которые успешно применяют аджайл во всей компании, в разговоре за обедом выяснилось, что работает это у них просто прекрасно, инвесторы/стейкхолдеры странными идеями их не душат, да и работа у Евгения, чтоб такого как раз не случалось. Докладчики жгли перлами и напалмом, и кажется разошлись на цитаты: "клизма для вдува таска в итерацию", "тз - хз", "разработчики делают маркетинг!" и другие, фишечка на финальном слайде с конец - "конь" была неочевидной! =). В кулуарах заслужили звание "наших" ажайл-гуру.
©
Докладчики из команды компании СКБ «Контур», разрабатывающей любопытный сервис — «Электронный бухгалтер Эльба». Идея — предоставить малому бизнесу сервис упрощенной бухгалтерии в интернет. На сайте есть ролик, наглядно объясняющий суть сервиса. Примечательно, что сервис включает также возможность электронного документооборота с органами отчетности. Впрочем, речь не о продукте, а о команде, процессе, и докладе.
Команда довольно большая — 18 человек, и весьма разношерстная (9 ролей!). Там и разработчики (8 шт), и бухгалтеры-аналитики, «интерфесологи», продвиженцы-маркетологи, дизайнер, юзабилист, и я еще парочку забыл.
Начинали в стиле водопада, но быстро (через пару месяцев) поняли бесперспективность этой затеи и начали двигаться маленькими итерациями, стараясь полностью реализовывать отдельные фичи. Поставили себе задачу «каждый месяц выпускать Real release», то есть такой релиз, где есть что-то существенно новое, а не мелочи и багфиксинг. Это очень правильный принцип, и им, вроде как, удается его выдерживать.
Что удивило:
- Они сидят в одной комнате (18 человек!). Считают это за достижение и говорят, что это им сильно помогает, но я реально не понимаю, как это возможно — или они по большей части молча работают.
- Если задачу оценили в N, а по ходу дела выясняется, что она скорее 3N, то вместо того, чтобы обозначить это, они начинают «списывать пропорционально». Мне кажется, это искажает раннюю информацию об «успеваемости».
Еще из любопытного:
- Они стараются делать такие вещи, как «презентации аналитиков и продвиженцев» — людей, работу которых очень сложно померить и пощупать. Но, стараются, просто чтобы команда была в курсе того, как идут дела.
- Вроде бы у них нет формального PM, хотя наверное, все-таки, кто-то такой есть.
- Позже, на Jam Session девушка по-моему именно из этой команды спрашивала, то делать с нудными и скучными скрам-митингами. Честно говоря, не удивительно при таком разбросе ролей в одной команде!
- Рисуют фичи (user stories) и таски на спринт в виде mind map’а. В любой момент его можно дорисовать, декомпозировав какую-то задачу, и разложив суммарную ожидаемую трудоемкость на части.
- Иногда они проводят «день ретроспективы», выезжая на базу отдыха. Думается, это классная практика, и не слишком накладная, на самом деле.
В общем, мне показалось, что до оптимальности процесса у них еще далеко, и скидывать столько разных ролей в одну команду — это слишком.
Что касается доклада, то он, увы, был довольно занудный. Рассказывали двое, но от обоих хотелось спать.
Доклад о том как внедряли SCRUM для всех ролей для продукта «Электронный бухгалтер Эльба» в компании «CКБ-Контур».
С точки зрения внедрения SCRUM достаточно скучно…
с бизнесовой точки зрения бизнеса, я узнал про этот проект когда он был на уровне бизнес-идеи… интересно, что он превратился в что-то реальное
Добротный доклад с максимумом конкретики, про то как одна небольшая контора делает SaaS для бухгалтерии в малом бизнесе, как все — и маркетологи, и сейлзы, и разработчики — совершают похожие телодвижения с развешиванием бумажек, совместным планированием и итерациями. Как сначала они потратили кучу времени на разработку МегаТЗ, а потом решили постепенно наращивать функционал и очень довольны. Как разработчики сознательно отбирают некоторый процент звонков у службы поддержки, чтобы лучше понимать пользователей (кстати, нам тоже стоит практиковать, это и правда полезно). Очень любопытный жаргон: «клизма» == «бонусная задача». Рисуют багзильное Древо Багов на бумажке. Хоть у них и Agile, а разделение ролей вовсю: разработчик, аналитик, инженерный психолог и дизайнер интерфейсов — это всё разные люди. В общем, ребята оставили хорошее впечатление.
Этот доклад был на первом месте по потенциальным слушателям, но моих надежд не оправдал. Потому что изложение, к сожалению, было очень медленным.
Речь идет о продуктовой разработке и они включили в команду всю цепочку, включая маркетинг. А начали с разработчиков.
Команда 18 человек, все в одной команте: 2 аналитика (грызут нормативку) + 1 инж.психолог + 2 проект.интерфейсов + 1 граф.дизайнер + 8 разр + 2 тестера + 1 менеджер + 1 документатор + 3 продвиженца.
Что интересно, в этой конструкции нет PO — поскольку есть много источников для задач, и как-то это совместно решается.
Интересная задача и предметная область — сделать что-то вменяемое из уежищной «стандартной бухгалтерии», минимальное столкновение с которой у нормального человека вызывает адский батхерт (вот хейт-спич Каганова только относительно простого банковского перевода, а бухгалтерия с ее негуманоидными правилами — полный ад по сравнению с этим). Собственно эта законсервированная ситуация, когда в любой компании приходится держать специально обученных бухгалтеров и 1Ц, как жрецов бессмысленного, но неизбежного культа. И наконец, для тех кто вроде прошел этот квест, остается общение с налоговой инспекцией, 100500 бессмысленных бумажных отчетов (еще бы, ведь налоговая мотивирована, чтобы налогоплательщики ошибались), ад, очереди, похороны времени.
Победить всего дракона сходу не вышло, сейчас сервис копает в сторону спасти от этого гемора, индивидуалов и упрощенщиков, но и то хорошо. Главное — они как-то наладили контакт с потусторонним миром, и налоговые отчеты попадают туда из сервиса сами. (Конечно, все это по-уму надо ждать от «Электронного правительства», но такое будет явно не в этой жизни).
Я даже зарегистрировался в сервисе, но попробовать демо не удалось — надо как-то заводится предпринимателем, а это отдельный, еще не автоматизированный квест. Но если уволят, и придется делать какой-нибудь стартап-ПБОЮЛ, то, наверное, заведусь.
Экстремальность же они понимают, как «беспредел» — у них явно изолированная задача, отдельная команда из пары десятков человек, и вместо того, чтобы выстраивать в ней оргструктуру (хотя бы на уровне выделения отдельного Product Owner-а), они решили все сделать просто и плоско. Практически разношерстная, но сбалансированная по навыкам команда, собравшаяся в миссию в какой-нибудь онлайн-игре. Цели задают в параллель разные люди — и аналитики по развитию функционала, и дизайнеры-юзабилисты, и отдельно юзабилисти-эргоносит («инжерер-психолог»). Задачи не просто падают россыпью на доску — а выстраивается план-майндмап по их уничтожению внутри итерации.
Внимание! Данная статья выбрана для репликации во внешнюю базу знаний компании. Пожалуйста, не допускайте в этой статье публикацию конфиденциальной информации, ведения обсуждений в теле статьи, и более ответственно относитесь к качеству самой статьи — проверяйте орфографию, пишите по-русски, избегайте непроверенной вами информации.
