Лого vc.ru

Прозрачная разработка

Прозрачная разработка

Степан Родионов, основатель компании по разработке программного обеспечения Antida software, написал для vc.ru колонку о том, как команде взаимодействовать с заказчиком, чтобы выстроить доверительные отношения и оптимизировать создание продукта.

Поделиться

Мы занимаемся разработкой ИТ-продуктов на заказ. Поскольку мы не развиваем свои собственные проекты, а создаём их для клиентов, для нас очень важно выстраивать с ними доверительные отношения. Как оказалось, на отношения очень влияет то, как именно ведётся разработка.

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

Тема взаимоотношений между исполнителем и заказчиком в сфере разработки ИТ-продуктов не нова. Компания «Стратоплан» в своей статье «Управленческие инструменты: Почему заказчики требуют дурацкие отчеты?» достаточно подробно разобрала этот вопрос, показав четыре стадии взаимоотношений и возможные переходы между ними. Формально их можно изобразить в виде матрицы.

Я не стану подробно описывать, что означает каждая из стадий. Скажу лишь, что наша задача такова: из квадрата A, когда доверие клиента и прозрачность процесса на низком уровне, перейти в квадрат C и остаться там.

Маршрут, которого следует придерживаться, выглядит следующим образом: A → B → C. Сделать это мы можем за счёт повышения прозрачности процесса — после этого установление доверительных отношений становится делом времени.

Почему нужно постараться остаться на стадии C? Если мы перейдём на стадию D, наше положение окажется очень неустойчивым, цена ошибки будет слишком велика — появится риск снова перейти к низкому доверию.

Что интересно, переход C → D практически всегда происходит из-за заказчика, по крайней мере если судить по моей практике. Заказчик просто расслабляется: может перестать участвовать в планированиях и ретроспективах, ведь всё и так отлично. Вслед за ним расслабляется команда разработчиков. В моей практике такое случалось дважды (Дмитрий, привет!). Клиент исправно платит деньги, но практически не участвует в операционном управлении проектом. Правда так стало только после года работы — после того, как мы спасли продукт и начали выпускать стабильные релизы.

Что мы делаем для удержания отношений в стадии C? Коротко: не расслабляемся. Не было клиента на стендап-митинге или ретроспективе? Значит, нужно отправить результат ему на почту. Рассказываем ему обо всех проблемах, вопросах или успехах.

Как добавить прозрачности

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

Предметная область проекта — строительство, сервис по подбору строительных подрядчиков. Модель схожа с «Яндекс.Мастером», только акцент сделан именно на строительные работы. Разработка велась по каскадной модели (waterfall): планировался определённый набор функциональности по ТЗ на некоторый срок, ребята уходили всё это реализовывать и потом разом выкатывали то, что получилось.

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

С таким заказчиком изначально труднее работать, потому что он очень недоверчив и во второй раз хочет видеть и контролировать абсолютно всё. Его можно понять, и ему нужно помочь. Инициатива в таких случаях всегда на нашей стороне. Что делать? Нам помогают приёмы из Agile software development. Я не видел ни одной команды, которая строго следовала какой-то определённой методологии. Обычно процесс выстраивается из комбинации разных приёмов, которые адаптируются под конкретную команду или проект. Так же поступаем и мы.

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

Story mapping

Обычно всё начинается с того, что нас просят оценить стоимость и сроки разработки проекта. Так же было и с этим заказчиком. Здесь все поступают по-разному, но мы сейчас преимущественно оцениваем проекты после story mapping. Объясню почему. Суть story map заключается в том, чтобы описать систему с точки зрения пользователя и разложить все сценарии по двум осям: время и приоритетность. Что это даёт?

  • И мы, и клиент чётко понимаем объём проекта: нам его гораздо проще оценить, а заказчик понимает, за что он платит.
  • Упрощается планирование релизов: мы понимаем, как будет развиваться продукт.

Реальный пример Story Map для первой версии проекта. На построение ушло два-три часа

После того, как будет построен первый вариант, скорее всего, последуют доработки. Получившаяся карта переводится в электронный вид, работа над ней не останавливается.

Подробнее о применении этой практики и её преимуществах перед обычным ТЗ я рассказал в статье «Story Mapping: мощный инструмент в арсенале разработчиков».

Частые релизы

Наш заказчик находился в следующей ситуации: требовалось разработать первую версию проекта (по объёму около 100 человекодней), которую нужно было продемонстрировать инвесторам, чтобы разработка продолжалась. Казалось бы, небольшой объём для команды из трёх человек, задачи для команды определены — что плохого может случиться за этот период? Но всё оказалось не так хорошо. Во многих случаях поведение системы было не таким, как рассчитывал заказчик, — в силу разных причин.

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

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

Непрерывная интеграция (Continuous Integration)

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

В данном случае это обусловлено двумя основными причинами: обратная связь и заказчик. Максимально быстро понять, что что-то пошло не так, как предполагалось, очень важно. Помимо этого, когда у клиента в любой момент есть доступ к последней версии продукта (пусть и не на 100% рабочей) — сами понимаете, это положительно сказывается на его отношении к команде.

Мы сразу объяснили клиенту ценность непрерывной интеграции для выпуска продукта, поэтому через некоторое время у проекта появился CI-сервер. Мы практически всегда используем TeamCity для обеспечения интеграции.

QA-менеджер

К работе над проектом мы обязательно подключаем QA-менеджера, который отвечает за качество продукта в целом. Это не просто тестировщик, который «протыкивает» проект по описанию задачи. Это человек, который полностью ведёт все сценарии использования системы, проверяет выполненные задачи, проводит регрессионное тестирование перед релизом. Его работа во многом определяет качество проекта — это его ответственность.

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

Правильная рабочая доска с задачами

Сейчас многие команды (даже те, которые не работают по гибким методологиям) используют в работе так называемые Agile-доски, чтобы у всех членов команды перед глазами были текущие задачи, их состояние и так далее. У нас используются виртуальные доски, чтобы и команда, и заказчик видели положение дел. Мы пробовали работать с AgileZen, Trello, TFS и YouTrack.

Основная проблема, которую мне часто приходилось видеть, — это неправильное разбиение на статусы (колонки). Когда задача «идёт» по доске, не должно возникать вопросов относительно её состояния. Вернёмся к команде, которая работала с нашим клиентом до нас: на их доске после статуса «Working» сразу был статус «Testing». Это неверно, потому что в таком случае нельзя однозначно определить, действительно ли эта задача сейчас тестируется или просто разработчик её выполнил и перенёс на следующий статус. И подобных примеров масса.

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

Беклог (Backlog) для доски формируется по построенной Story Map в соответствии с приоритетом, обозначенным заказчиком.

Стендапы (Standup Meeting)

Про стендап-митинги все знают, но не всегда используют на практике. Эти мини-планёрки длительностью не более 15 минут имеют большую ценность для проекта.

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

Разработчики любят переводить разговор в слишком техническую плоскость. Например, могут сказать: «Я написал миграцию, которая заменяет связь один-к-одному на один-ко-многим», вместо того чтобы сказать: «Я реализовал возможность добавления нескольких категорий для публикации вместо одной». Такие вещи нужно модерировать. Заказчику интересно услышать о результатах с точки зрения бизнеса, а не технической реализации.

Demo

После окончания каждой итерации (у нас она длится неделю) мы проводим демонстрацию проделанной работы клиенту. Показываем всё, что было сделано или исправлено. Нужно именно продемонстрировать, а не просто отправить заказчику ссылку на dev-сервер, где он сможет посмотреть всё сам. Он и так посмотрит, только уже после демо.

Во время демонстрации мы стараемся сразу получать обратную связь и проводить обсуждения, делать какие-то пометки, фиксировать замечания на доске. Демо — очень важная составляющая разработки, приятно волнительная. У нас в демо принимает участие вся команда, а проводит его тимлид или QA-менеджер.

Заключение

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

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

Популярные статьи
Показать еще
Комментарии отсортированы
как обычно по времени по популярности

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

Вопрос не разработки, а отношений.

Согласен, это всё -- важная составляющая процесса разработки в целом. Просто я рассказал об этом именно с точки зрения взаимодействия с клиентом.

Ждём историю, как приобрести диссидента в лице уборщицы, после story map на окнах :)

Уборщицы обычно обучены и знают, что стикеры убирать не стоит.

0

Спасибо за статью, все описанное очень здраво.

0

Спасибо за отзыв, Станислав.

0

Отличная статья!
Вот так и надо работать!
Степан Родионов, вы - молодец!

0

Лев, большое спасибо за положительный отзыв.

0

Рад за Степу, что он развивается,ю после увольнения из моей компании, но надо иметь совесть и давать ссылки на оригинал blog.byndyu.ru/2015/02/customer-satisfaction.html

Благо убрал наши проекты из своего портфолио

Сань, привет. Спасибо за отзыв.

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

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

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

0

А вообще, мог бы позвонить/написать мне и лично объяснить мне свою позицию.

0

P.S. По твоей фразе можно двояко подумать, на всякий случай уточню. Из byndyusoft меня не увольняли, а я уволился оттуда.

0

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

Сейчас обсуждают
Alexey Petrov

80 процентов адекватной правды. С темой про сайт и визитки я не соглашусь ибо это мастхэв, да и домен с почтой типа раундкьюб стоит 10 баков в год + 3 бака в год. Так что тема с джимэйлом, если честно, то отстой. А в остальном кекс прав - деньги нужно делать и товар толкать, а брендформировать путем качественной работой. :) офис тоже тема такая, деньги жрущая, а на ранних этапах бонуса от нее ноль.

«iPhone последней модели у нас появился только когда мы заработали первый миллион»
0
Анатолий Тарасов

КоАП любого из регионов запрещает мойку во дворах и т.п. Штраф в МСК вроде пятерка.
Есть как минимум один из способов помыть машину где угодно, но наша команда признала этот способ нерентабельным)

Sparkl — сервис по заказу мойки автомобиля на парковке
0
ivan krapivin
Летим Куда Хотим

По крайней мере мне понятно, что объединяет этих людей. Это, как минимум, смешные фамилии.

«Я видел, как людей увозили в степи Казахстана в рабство. Это дисциплинирует»
0
Алексей Чингуль

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

После чего, хочу тебе прояснить, что у человека которого воруют из его уникальных знаний и способностей НЕТ НИКАКИХ вариантов и возможностей. Всё, он раб до конца своей жизни.

Если ты этого не понимаешь, то ты недалёкий долбаёб. Смею это утверждать.

Технологии картелей
0
Кирилл Бунаков

Толковые комментарии о причинах аварии от специалиста-ракетчика www.facebook.com/permalink.php?story_fbid=1228504033880007&id=100001612675483

SpaceX назвала предварительную причину взрыва ракеты Falcon 9 на стартовой площадке
0
Показать еще