Agile *

7 команд и ни одного менеджера – думаете, такое возможно? Мы построили процесс, в котором показываем на каждом демо по 1-2 фичи от команды, проводим ретро команд, ретро релизов и при этом получаем реальное удовольствие от работы. Хотите организовать свою работу так же? Тогда добро пожаловать под кат.



Мы, компания Renga Software, занимаемся разработкой программных продуктов для проектирования зданий и сооружений в соответствии с технологией информационного моделирования (BIM). Идем спринтами, выпускаем релизы каждые 3-4 месяца. Пользователей системы с каждой неделей становится всё больше. Продукт совсем молодой, поэтому бэклог переполнен важными, а главное, интересными задачами. Но как в короткие сроки разработать продукт, который будет использоваться для проектирования жилых домов, детских садов, больниц и театров?

Привет! Меня зовут Стас, я Product Owner команды «Welcome Aboard». Мы делаем удобный продукт для соискателей, желающих устроиться работать в Альфа-Банк.

Зачем нужен этот продукт? Чтобы сделать процесс общения кандидатов с банком приятнее и эффективнее на каждом шаге. Кроме того, это неслабо экономит время нашим рекрутерам, а довольный рекрутер – это всегда хорошо.

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



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

Поход

Главный герой (Эл) ведет в поход школьников — класс своего сына. Задача — дойти до Чертова ущелья засветло, переночевать там и, на следующий день, вернуться обратно. Детишки выстраиваются в шеренгу по одному и отправляются в путь. Первым идет Эл, остальные — как придется. Строй растягивается и главному герою приходится перебраться в конец чтобы никто не потерялся. Тогда главный герой перестает видеть голову строя, что тоже его беспокоит. Он пытается сообразить как так получается и первое что видит главный герой — толстый мальчик, которому идти тяжелее чем другим. После небольшого привала и перепалки ребятишек из-за задержки, они снова отправляются в путь и поведение толстячка изменяется — теперь он не отстает от впереди идущего т.к., вероятно, ему стало стыдно, что он задерживает всех. Теперь при накоплении отставания от впереди идущего, он переходит на бег. Теперь толстячок тратит сил больше чем другие — надолго ли его хватит?

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

В пятницу, 15 декабря в офисе Туту.ру пройдет очередной Agile Kitchen. Темой встречи станет практика и теория масштабирования Agile. Своими кейсами и опытом поделятся эксперты из Сбербанка, ScrumTrek, EPAM и других компаний. Вас ждут интереснейшие доклады и ставший уже привычным игровой трек.

У нас в Wrike есть традиция делиться с командой мыслями о книгах, которые прочитали. Мы давно думали, что было бы неплохо распространить эту инициативу и на наш блог на Хабрахабре, и вот подвернулся хороший случай — книга Фредерика Брукса «Мифический человеко-месяц».

Книгу можно назвать скорее классикой фольклора разработки, нежели реальным руководством по построению рабочего процесса. В ней отражены проблемы, с которыми Брукс столкнулся при организации работы над созданием операционной системы OS/360, и его подходы к их решению. Результат был далек от идеала, на что сам Брукс и указывает. Его целью было не научить как правильно, но поднять проблемы, требующие решения. Любопытно разобраться, что изменилось в разработке с 1960-х годов.


Фото из архива IBM

Julie Zhuo, директор по продуктовому дизайну в Facebook, однажды выступала на «TNW Europe», и рассказывала о фрэймворке, который используется в Facebook, чтобы сфокусироваться на разработке продукта.

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

Этот список не идеальный и не полный. Если бы была какая-то пошаговая инструкция (Шаг 1: Идея. Шаг 2: ??? Шаг 3: Профит!), тогда я бы потратила на неё хорошие деньги, а потом похлопала нас по спинам и смотрела бы, как новые потрясающие продукты цветут вокруг нас, словно цветочные поля в мае.

Путешествие завершено на 1%. Давайте продолжим идти дальше и обучаться.

Фрейминг

1. Продукт успешен, потому что решает проблемы за людей. Это звучит очень просто, но это самая важная вещь, которую нужно понимать в создании хороших продуктов.
2. Первым шагом в создании чего-то нового является понимание того, какую проблему ты хочешь решить и для кого. Это должно быть предельно ясно до того, как вы начнете думать над решением.
3. Третий вопрос, который вы должны себе задать: «Почему именно эту проблему стоит решать?»
4. Если аудитория, для которой вы создаете, узко определена (и вы её часть), то вы можете положиться на свою интуицию, чтобы принимать решения по продукту. Если же нет, то стоит полагаться на исследования и данные.
5. Если вы — основатель стартапа, будет легче начать с решения проблем узкой аудитории, а затем расширяться к общей аудитории после того, как вы заручитесь изначальной поддержкой.
6. Проблема, которую вы пытаетесь решить, должна быть поняла за пару предложений и резонировать с кем-либо из вашей целевой аудитории. Если этого не происходит, то считайте это тревожным признаком.

Долгое нахождение в зоне комфорта ведёт к проблемам

Однажды, когда держала в руках карты для planning-poker с 5 ценностями SCRUM, я поняла, что отдельные ценности в нашей команде «проседают». Хотя в команде мы исповедуем именно их.

1. Иногда мы перестаем слышать заказчика, не достаточно погружаемся в задачу и не стараемся решить проблему заказчика на глубоком уровне. Это происходит по причине того, что мы достаточно долго работаем в зоне своей ответственности. И фокус нашего внимания постепенно сужается до круга наших непосредственных задач. На проблемы окружающих людей мы просто перестаём обращать внимание.
2. В силу проблемы, обозначенной пунктом выше, члены команды иногда могут позволить себе резко ответить коллегам, если те чего-то долго не могут понять. Такое отношение не стимулирует к открытости, в следующий раз человек лучше потратит несколько лишних часов, чем снова обратится за помощью.
3. Долгая работа в одной и той же зоне ответственности приводит к шаблонности мышления. Иногда мы решаем задачи по «накатанному» пути из-за боязни выйти из зоны комфорта, столкнуться с чем-то новым и даже банальной лени глубже исследовать вопрос.
4. Отдельные члены команды недостаточно открыты шарингу знаний из-за интровертности характера.

Всем привет! Тема Agile вечна, вот и в нашем офисе не так давно прошла ScrumTrek’овская кухня. На этот раз обсуждали работу с требованиями, искали новые подходы к разработке и решали, как найти ценность для продукта.

На встрече было 10 докладов от спикеров из М.Видео, ScrumTrek, ZeptoLab, Альфа-Банка, Сбербанка, Citigroup, EPAM, Renault Digital и Look At Media. Программа была насыщенная, так что не проходите мимо, наверняка найдёте что-то для себя интересное. Комментарии приветствуются!

Для особо нетерпеливых есть лайфхак: последней строкой я добавлю ссылку на все видео разом. Не благодарите.

Наверное, на Хабре не найдется человека, не слышавшего про Scrum – самую популярную в наше время методологию управления разработкой программного обеспечения. Обилие публикаций от «коучей», компаний, только начинающих работать по принципам Agile, или уже испробовавших их на практике, руководителей проектов и обычных разработчиков, довольных и недовольных, любящих и ненавидящих Scrum всем сердцем, всех их мы читали уже не раз.

Обычно, говоря про Scrum, люди говорят только про разработку софта, но сегодня Кодабра расскажет кое-что необычное, мы поведаем вам свой опыт использования гибкой методологии для «разработки» самого настоящего оффлайн-мероприятия с живыми людьми вместо кода, площадками вместо серверов и самой требовательной аудиторией – детьми. Это рассказ про необычный подход к организации крупнейшего в России фестиваля цифровых технологий для детей и подростков – Digital Fest 2017.

Продакт оунер. Владелец продукта. Продуктолог. PO.



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

О том, кто такой продакт в понимании Альфа-Банка, что это за человек, что он умеет делать и как относится к своей команде, нам рассказал VDavydov Владимир Давыдов, руководитель по развитию цифровых каналов и продуктов Блока “Массовый бизнес”

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


В центре кадра — Julie Zhuo, product design director в Facebook

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

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

Учитывая что в Уфе зима приближается решительными марш-бросками, почему бы не поехать в конце октября на конференцию, куда-нибудь, где +20, и хоть немного, напоследок перед зимой, увидеть солнышко? Сказано-сделано: посмотрел конференции, сравнил докладчиков, посмотрел где еще есть early-bird access цены — и забронировал.

В этом году мы с коллегой разделились, и поехали на Agile Greece и Agile Turkey, дабы сравнить мероприятия, ну и рассказать что интересного было на каждой из них. Неоспоримы плюс Agile Turkey в этом году был открывающий доклад от Дейва Сноудена (создателя фреймворка cynefin, о которой вскользь писали на хабре). Обычно на подобных конференциях после докладов, спикеров облепляют заинтересованные, и свои вопросы задать и подискутировать не получается, что и было моим опасением, так как спросить надо было много.

Конференция и организация

Agile Turkey Summit проходит уже не первый год, в отеле Wyndham Grand Levent в Стамбуле (в активно строящемся небоскребно-деловом районе Maslak). Продолжается мероприятие всего 1 день (выпавший в этом году на 19 октября), хотя мастер-классы и воркшопы прошли еще 18-го числа. 4-й конференц-этаж отеля явно неспособен принять ~800 посетителей, что особенно очевидно, когда всех пытаются накормить.

Есть исследования и великолепная инфографика о том, как Agile распространен в мире. Этим можно вдохновиться, но выводы очень далеки от нашей действительности. Там попросту очень мало респондентов с постсоветского пространства.

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

Мы регулярно делаем выводы из прямого общения с клиентами. Собираем все хотелки по системе от пользователей и строим картину обращений. Но самое большое количество прозрений появилось сейчас, после запуска опроса. Уже набралось 300 респондентов (цель 1500) и можно посмотреть и обсудить первые результаты.

Можно ли сказать, что что-то из Agile используется в вашей компании?

Под катом первые графики, выводы, рассуждения и призыв пройти опрос.

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

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

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

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

Пару лет назад я уже рассказывал о нëм на HR Unconference. Но записи выступления нет, а знакомые, которые не могут найти себе людей в отдел, всë чаще интересуются деталями, так что я решил, наконец, подробно всë расписать, а заодно и опубликовать свой первый пост на Хабре, поделившись своими наработками с широким кругом читателей.

Пару лет назад я заходил к родственнику. Моему бедному кузену (а он генеральный директор страховой компании) продали «серебряную пулю Agile» — но она не сработала, и его это очень расстроило:

Чушь всё это! Мы начали делать всё совершенно иначе. Мы пригласили консультантов. Мы наняли специальных руководителей проектов. Не сработало! Ничего не изменилось. Никто ни за что не отвечает. Я слышу только оправдания.

Не помню, что я ответил тогда, но знаю, как ответил бы сегодня. Я бы набросал несколько рисунков, словом не упомянув Agile. Пришлось бы объяснить кузену несколько основных понятий…

Переведено в Alconost

1. КПД процесса

Мы провели опрос наших пользователей на тему “Нужна ли коробочная версия системы управления проектами?”. Для нас точный ответ на этот вопрос имеет большое значение. Определяет путь развития системы и приоритеты по новым функциям.



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

Под катом графики с результатами и наши выводы.

«У вас не будет второго шанса произвести первое впечатление» — этот афоризм прекрасно характеризует ситуацию, возникающую при введении новых услуг в эксплуатацию в сфере IT. В 2016 году Mars IS перешел на новую операционную модель, состоящую из 48 процессов, взаимосвязаных между собой, с тем чтобы обеспечивать эффективное функционирование IT-услуг. Наряду с такими широко используемыми процессами, как управление инцидентами, проблемами, изменениями и др., в новую операционную модель вошел процесс введения новых услуг в эксплуатацию (Service Introduction).

С одной стороны, программисты – мягко говоря не самые общительные люди на свете. Это нормально, ведь если разработчики вдруг станут разговорчивыми кто будет писать код? С другой – время одиночек прошло. Современное ПО разрабатывается командами и даже самые консервативные компании, вроде Сбербанка внедряют Agile. Agile manifest пропагандирует определенные ценности, в том числе: «Люди и взаимодействие важнее процессов и инструментов». Так что общение с коллегами – не прихоть, а потребность. Эта статья ориентирована на гибкие команды разработки: разработчиков, тим-лидов, аналитиков, тестировщиков и т.д.

Профессиональные PM вряд ли найдут здесь что-то новое. Если вы – «технарь» и хотите, чтобы вас как можно меньше отвлекали от основного вида деятельности и вам интересно при чем здесь Спарта, добро пожаловать под кат.

Если оторваться от Хабра, заглянуть в реальную российскую компанию старше 30 лет и больше чем с тысячью сотрудников и произнести слово Agile, то реакция будет как минимум настороженная. Люди там уже слышали истории похожие на «Как рассказать бабушке» или "Как рассказать дедушке" и посмотрели все выступления Грефа, получили с десяток предложений внедрить гибкость за неделю, кто-то из сотрудников даже поработал год со Scrum, но остается один вопрос:

«Что с этим нам делать то, у нас из программирования только сайт?»

В итоге примерно для 100% компаний Agile смахивает на шарлатанство.


Но вот парадокс — в мире 77% компаний*, использующих Agile в проектах, занимаются совсем не разработкой программного обеспечения.

_{*Из большого ежегодного опроса компаний от VersionOne}

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