У молодых компаний-разработчиков программного обеспечения одна из наиболее важных проблем, встающих на пути развития, заключается в невысоком уровне лояльности (доверия) [потенциальных] клиентов. В общем-то со временем, при условии качественной работы, она постепенно устраняется естественным образом. Однако, каким способом можно ускорить решение этого вопроса? Один из вариантов — организация прозрачного процесса разработки.
Недавно к нам в компанию «пришел» клиент, отказавшийся от продолжения сотрудничества с другим подрядчиком. Причины стандартные. Разработчики создавали продукт по принципу черного ящика: определялся список задач, они уходили все это делать, а потом разом выкатывали клиенту все, что получилось. Отсюда куча проблем, постоянное недоверие клиента, т.к. он не понимает, чем это время занималась команда, действительно ли столько времени им нужно было, и если да, то почему в результате клиент все равно остался недоволен. Отсюда результат: продукт получился не таким, каким его ожидал увидеть клиент, подпорченные отношения и репутация. Проигрышная ситуация для обоих.
У нас получилось выправить ситуацию за счет организации прозрачного процесса разработки. При работе с предыдущим подрядчиком, заказчику приходилось много времени тратить на техническую составляющую проекта, заниматься постоянными проверками разработчиков, вместо того, чтобы концентрироваться на бизнесе. Сейчас клиент в любой момент времени понимает на каком этапе находится проект, имеет возможность корректировать ход работ, дает нам быструю обратную связь.
Мы уже достаточно давно выработали для себя наиболее удачный вариант комбинации нескольких гибких методологий разработки ПО, который успешно применяем (иногда он меняется в деталях и подстраивается под конкретный проект). Далее будут описаны основные составляющие нашего процесса, которые, по моему мнению, больше остальных влияют на скорость установления доверительных отношений разработчиков с клиентами.
На помощь приходят гибкие методологии разработки. По моему опыту, команды никогда не соблюдают строго одну методологию, например, Scrum или Kanban, чаще всего каждая команда просто адаптирует под себя комбинации практик из различных методологий. Например, мы используем практически все приемы из экстремального программирования, кроме, скажем, Planning Poker. В результате таких экспериментов с адаптациями методологий выстраивается процесс, который в наибольшей степени подходит команде.
Мы поняли слабые места процесса разработки предыдущей команды и устранили их путем введения в процесс нескольких важных составляющих, которые непосредственно связаны с взаимодействием с клиентом. Вот наиболее важные из них.
Процесс строился примерно следующим образом. Мы планируем определенный набор функционала, который нужно выполнить на текущем этапе. Объем работ, к примеру, соответствует месяцу разработки, однако это не мешает нам выпускать релизы продукта еженедельно (по факту — ежедневно), добавляя новые возможности постепенно, а не единоразово. Таким образом, в месяц мы выпускаем 4 обновления, вместо одного. Это дает нам возможность получать обратную связь и реагировать на нее максимально быстро.
Непрерывная интеграция является неотъемлемой частью качественной разработки. Любые изменения должны автоматически попадать на тестовый стенд в полностью собранном виде, где их должен проверить QA-инженер. В данном случае на то есть две основные причины: обратная связь и клиент. Максимально быстро понять, что что-то пошло не так, как предполагалось, очень важно. Помимо этого, когда клиент может в любой момент времени иметь доступ к самой последней версии продукта (пусть не всегда 100% рабочей), положительно сказывается на его лояльности в целом.
Прежде всего, доска, на которой отражается процесс разработки вообще должна быть :) Но неправильное разделение доски по статусам может оказать негативное влияние на проект. Когда задача «идет» по доске не должно возникать сомнений, что именно происходит с задачей и в каком она статусе. Под этот проект у нас были определены следующие колонки: Backlog — Todo — In work — Done — Testing — Resolved — Deploy. В другом случае, скорее всего, будет другой набор. Важно чтобы эти колонки соответствовали естественному ходу задачи и не были двусмысленными.
К команде должен быть подключен QA-инженер, отвечающий за качество продукта в целом. Это не просто тестировщик, который «протыкивает» систему по описанию задачи. Это человек, который ведет полностью все сценарии использования системы, тестирует новые задачи, проводит регрессионное тестирование. Его работа во многом определяет качество выпускаемого продукта, поэтому такой человек обязательно должен быть привлечен к работе.
Стендап митинги — про них все знают, но реально не все используют. Эти мини-планерки длительностью не более 15 минут несут огромную пользу команде и проекту в целом. Каждое утро (или до обеда) созваниваемся в Skype с клиентом и каждый член команды рассказывает о том, что было сделано за вчерашний день, какие возникли проблемы, как они решаются или решились, а также подписывается на то, что будет сделано сегодня. Такая практика, помимо всего прочего, постепенно повышает уровень доверия между клиентом и командой. [В Kanban, кстати, стендапы проходят по-другому]
После окончания каждой итерации, нужно демонстрировать клиенту проделанную работу. Показывать нужно все, что было сделано или исправлено. Демонстрировать, а не просто дать ссылку на dev-сервер, где клиент может сам все посмотреть. Он и так посмотрит сам, но после вашей демки. Важно сразу же получить обратную связь, возможно, провести какие-то обсуждения. Демонстрация — очень важная составляющая. Приятно волнительная. Принимает участие вся команда, но непосредственно демонстрирует кто-то один: тимлид или QA-инженер.
В этой статье я перечислил несколько основных составляющих процесса разработки ПО, которые позволили нам выстроить лояльные отношения с клиентом, имеющим неудачный опыт сотрудничества с другой командой. Конечно, гибкие методологии предлагают гораздо больше различных методов, многие из которых мы используем, однако здесь я привел именно те, которые, по-моему, больше остальных важны для выстраивания прозрачного процесса и доверительных отношений клиентов с исполнителями.
Стоит отметить так же то, что для выполнения подобных техник и поддержания высокого темпа, команда разработчиков должна быть достаточно высокого уровня. Особенно это касается практик экстремального программирования, основные тезисы которого направлены именно на инженерную составляющую.
Спасибо за внимание. Надеюсь, начинающим командам с еще не до конца поставленными процессами, статья окажется полезной.
Scrum и Kanban: выжимаем максимум, Х. Книберг и М. Скарин.
Экстремальное программирование, К. Бек.
Бережливое производство программного обеспечения, М. Попендик и Т. Попендик.
Недавно к нам в компанию «пришел» клиент, отказавшийся от продолжения сотрудничества с другим подрядчиком. Причины стандартные. Разработчики создавали продукт по принципу черного ящика: определялся список задач, они уходили все это делать, а потом разом выкатывали клиенту все, что получилось. Отсюда куча проблем, постоянное недоверие клиента, т.к. он не понимает, чем это время занималась команда, действительно ли столько времени им нужно было, и если да, то почему в результате клиент все равно остался недоволен. Отсюда результат: продукт получился не таким, каким его ожидал увидеть клиент, подпорченные отношения и репутация. Проигрышная ситуация для обоих.
У нас получилось выправить ситуацию за счет организации прозрачного процесса разработки. При работе с предыдущим подрядчиком, заказчику приходилось много времени тратить на техническую составляющую проекта, заниматься постоянными проверками разработчиков, вместо того, чтобы концентрироваться на бизнесе. Сейчас клиент в любой момент времени понимает на каком этапе находится проект, имеет возможность корректировать ход работ, дает нам быструю обратную связь.
Мы уже достаточно давно выработали для себя наиболее удачный вариант комбинации нескольких гибких методологий разработки ПО, который успешно применяем (иногда он меняется в деталях и подстраивается под конкретный проект). Далее будут описаны основные составляющие нашего процесса, которые, по моему мнению, больше остальных влияют на скорость установления доверительных отношений разработчиков с клиентами.
Как добавить прозрачности?
На помощь приходят гибкие методологии разработки. По моему опыту, команды никогда не соблюдают строго одну методологию, например, Scrum или Kanban, чаще всего каждая команда просто адаптирует под себя комбинации практик из различных методологий. Например, мы используем практически все приемы из экстремального программирования, кроме, скажем, Planning Poker. В результате таких экспериментов с адаптациями методологий выстраивается процесс, который в наибольшей степени подходит команде.
Мы поняли слабые места процесса разработки предыдущей команды и устранили их путем введения в процесс нескольких важных составляющих, которые непосредственно связаны с взаимодействием с клиентом. Вот наиболее важные из них.
Частые релизы
Процесс строился примерно следующим образом. Мы планируем определенный набор функционала, который нужно выполнить на текущем этапе. Объем работ, к примеру, соответствует месяцу разработки, однако это не мешает нам выпускать релизы продукта еженедельно (по факту — ежедневно), добавляя новые возможности постепенно, а не единоразово. Таким образом, в месяц мы выпускаем 4 обновления, вместо одного. Это дает нам возможность получать обратную связь и реагировать на нее максимально быстро.
Continuous Integration
Непрерывная интеграция является неотъемлемой частью качественной разработки. Любые изменения должны автоматически попадать на тестовый стенд в полностью собранном виде, где их должен проверить QA-инженер. В данном случае на то есть две основные причины: обратная связь и клиент. Максимально быстро понять, что что-то пошло не так, как предполагалось, очень важно. Помимо этого, когда клиент может в любой момент времени иметь доступ к самой последней версии продукта (пусть не всегда 100% рабочей), положительно сказывается на его лояльности в целом.
Правильная доска
Прежде всего, доска, на которой отражается процесс разработки вообще должна быть :) Но неправильное разделение доски по статусам может оказать негативное влияние на проект. Когда задача «идет» по доске не должно возникать сомнений, что именно происходит с задачей и в каком она статусе. Под этот проект у нас были определены следующие колонки: Backlog — Todo — In work — Done — Testing — Resolved — Deploy. В другом случае, скорее всего, будет другой набор. Важно чтобы эти колонки соответствовали естественному ходу задачи и не были двусмысленными.
QA-инженер
К команде должен быть подключен QA-инженер, отвечающий за качество продукта в целом. Это не просто тестировщик, который «протыкивает» систему по описанию задачи. Это человек, который ведет полностью все сценарии использования системы, тестирует новые задачи, проводит регрессионное тестирование. Его работа во многом определяет качество выпускаемого продукта, поэтому такой человек обязательно должен быть привлечен к работе.
Standup Meeting
Стендап митинги — про них все знают, но реально не все используют. Эти мини-планерки длительностью не более 15 минут несут огромную пользу команде и проекту в целом. Каждое утро (или до обеда) созваниваемся в Skype с клиентом и каждый член команды рассказывает о том, что было сделано за вчерашний день, какие возникли проблемы, как они решаются или решились, а также подписывается на то, что будет сделано сегодня. Такая практика, помимо всего прочего, постепенно повышает уровень доверия между клиентом и командой. [В Kanban, кстати, стендапы проходят по-другому]
Demo
После окончания каждой итерации, нужно демонстрировать клиенту проделанную работу. Показывать нужно все, что было сделано или исправлено. Демонстрировать, а не просто дать ссылку на dev-сервер, где клиент может сам все посмотреть. Он и так посмотрит сам, но после вашей демки. Важно сразу же получить обратную связь, возможно, провести какие-то обсуждения. Демонстрация — очень важная составляющая. Приятно волнительная. Принимает участие вся команда, но непосредственно демонстрирует кто-то один: тимлид или QA-инженер.
Заключение
В этой статье я перечислил несколько основных составляющих процесса разработки ПО, которые позволили нам выстроить лояльные отношения с клиентом, имеющим неудачный опыт сотрудничества с другой командой. Конечно, гибкие методологии предлагают гораздо больше различных методов, многие из которых мы используем, однако здесь я привел именно те, которые, по-моему, больше остальных важны для выстраивания прозрачного процесса и доверительных отношений клиентов с исполнителями.
Стоит отметить так же то, что для выполнения подобных техник и поддержания высокого темпа, команда разработчиков должна быть достаточно высокого уровня. Особенно это касается практик экстремального программирования, основные тезисы которого направлены именно на инженерную составляющую.
Спасибо за внимание. Надеюсь, начинающим командам с еще не до конца поставленными процессами, статья окажется полезной.
Ссылки
Scrum и Kanban: выжимаем максимум, Х. Книберг и М. Скарин.
Экстремальное программирование, К. Бек.
Бережливое производство программного обеспечения, М. Попендик и Т. Попендик.