Блог

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

Зачем нужен регламент при командной разработке

Приходит заказчик со «срочной» доработкой. Он знает, что такое сайты, веб-разработка, верстка, хостинги, и вообще, его не проведешь. Менеджер принимает задачу в работу, разработчик оценивает ее в 1 час, и она ставится в релиз с датой публикации через 2 недели. Опля... У заказчика недоумение. Какие две недели, тут делов-то, сами же оценили в 1 час?

Представим, что административный рычаг у заказчика очень большой, он настаивает на немедленной публикации, и смотрим, что происходит на практике:

Менеджер: Так, парни, задачу № 17357 надо срочно опубликовать.

Разработчик: Я вчекинил в ветку 96-го релиза.

Менеджер: Чтобы все не выкладывать, можно подложить на бой одну библиотеку?

Разработчик: Да.

Администратор: Это против правил.

Менеджер: Воот такой рычаг.

Администратор. Хорошо, обновляю.

 

Прошел час.

 

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

Менеджер: Откатываем библиотеку к исходному состоянию.

Разработчик: Можно, но в базу уже в течение часа пишутся измененные новой библиотекой данные.

Менеджер: Так... сколько записей в базе создалось с момента обновления?

Разработчик: 115

Менеджер: Библиотеку возвращаем, после записи руками апдейтим, пользователям пишем, что починили. Фуух, вроде разобрались. (Проверяет базу.) Шит, кривые данные продолжают писаться!

Администратор: Ах ты ж... Я не все серверы кластера обновил, один с измененной библиотекой остался.

 

Проходит 10 минут.

 

Менеджер: А что у нас в CRM после обновления ушло?

Тестировщик: То же самое, что в базу писалось...

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

 

Заказчик (по телефону): Ребят, я там в задаче неточно сформулировал, в общем, переделать надо.

Менеджер (про себя): Да я ж тебя...

 

Итог этой истории: «срочная» задача заказчика не решена, время потрачено, не сделаны другие запланированные ранее задачи, партнеры из CRM недовольны, сотрудники между собой переругались. А также самое важное: Клиенты получили неработоспособный функционал.

 

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

***

Что на самом деле нужно заказчику? Ему нужно, чтобы Клиент был доволен. Проводя внеочередную неоттестированную выкладку на площадку, что мы делаем по сути? Мы стираем проверенный (тестировщиками и временем) работоспособный код и заменяем его на нечто не до конца изученное и непредсказуемое. Да, непроверенная сборка именно так и называется. Ради чего мы так поступаем? Обычно ради того, чтобы поскорее выложить обновленную функциональность. А какие есть объективные причины для такой спешки? Уже опубликовали анонс? Это не объективная причина, это кто-то поторопился и несогласованно проанонсировал. Топ-менеджер настаивает? Это не объективная причина, а субъективная. Если хорошо подумать, то найти причины для спешки сложно. Не без исключений, конечно, но в общей массе именно так: объективных причин для спешки нет. В той области IТ-проектов, которой мы занимаемся. А если нет, добро пожаловать с задачкой в план на следующий релиз.

Итого, что лучше для заказчика: полностью довольный Клиент через неделю или довольный Клиент сегодня, но с вероятностью 50%?