Блог

Всеволод Фролов
Начальник отдела управления проектами

Почему мы исповедуем принципы открытости и честности в разработке

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

Что получается, когда нет открытости

Когда группа разработчиков не афиширует то, чем они занимаются, происходит следующее.

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

В итоге чувство собственной важности растет, а качество продукта падает.

Почему быть открытыми — это хорошо?

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

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

Хорошо ли, если коллега укажет тебе на твои промахи? Для человека, постоянного совершенствующего свои профессиональные навыки, — это хорошо, этим он отличается от любителя.

Как устроено у нас

Наша борда* живет в веб-интерфейсе и доступна для просмотра любому сотруднику офиса.

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

Отношение к ошибкам

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

Несколько ситуаций, когда задача не сделана в срок, и что с ними делать

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

Я не понял задачу. Для того чтобы избежать недопониманий, используется принцип «я не начинаю делать задачу, пока не задам всех вопросов и мне не станет все по ней понятно». Постановщик задачи никогда не откажет разработчику в объяснении неясных моментов. Иначе слабым звеном станет постановщик, который «желает странного» :)

Я не увидел описания определенного момента и сделал по-своему. В этом случае формально будет виноват автор задачи. Но разработчик, который поднимает вопрос про неописанную часть предметной области, — он молодец. Что же заставит разработчика стать молодцом и попросить уточнения? Его заставит то обстоятельство, что переделывать задачу придется ему самому, а не автору задачи.

Не моя область ответственности. Если задачу делают два человека и определенную часть задачи может выполнить каждый из них, есть вероятность, что в итоге каждый понадеется на другого и эту часть задачи не сделают ни первый, ни второй. Итог, как правило, один — доделывать в спешке, вечером или на выходных. Чтобы проблему такого рода не допустить, нужно как можно более четко распределить области ответственности между сотрудниками.

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

*Борда (ударение на последнем слоге, сленг., от англ. board)  доска, список задач, которые выполняет команда в текущей итерации в рамках гибкой методологии разработки.