Аркадий Чугунов
30 апреля 2015
Советы почтой каждую неделю
Пожалуйста, получите наше письмо, чтобы подтвердить свой адрес:
Вы подписаны на «Советы за неделю»:

Как при ФФФ работать с багами? Они копятся за время существования текущей версии продукта и возникают в процессе разработки следующей. Некоторые из них разработчики правят на лету, некоторые откладывают в бэклог, из которого при планировании выбирается пачка для исправления в следующей версии. Но по факту получается, что баги все равно могут неконтролируемо увеличить срок разработки. Как с этим бороться?


Аркадий!

Любые неожиданности неконтролируемо увеличивают срок разработки. Упрощение или отказ от функциональности ради соблюдения сроков и сохранения высокого качества конечного продукта (ФФФ) — универсальная реакция на любые неожиданности, и на баги в том числе.

Когда багов много, возникает соблазн провести итерацию доработки и всё починить. Не советую так поступать. Польза такой итерации размыта, флексить трудно, результат непредсказуем.

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

Исправляйте ошибки по ходу работы над чем-то полезным для бизнеса.

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

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

Чтобы изменить шаблон, пришлось бы переделать систему работы с клиентами во всей компании и переучить специалистов. В короткой итерации это было невозможно, но к письму нашего сервиса мы уже прикоснулись и не могли оставить его как есть. Мы переделали только наше письмо и рекомендовали клиенту переделать остальные в будущем:

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


Иллюстрация божественного касания из совета Антона Шнайдера
P. S. Это был совет об управлении проектами, людьми и собой. Присылайте вопросы.

P. P. S. Я проведу практический курс «Управление проектами, людьми и собой» 7, 8 и 9 апреля в Москве

 

Запись открыта до СБ 1 апр


Поделиться

Комментарии

Михаил Озорнин
30 апреля 2015

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

Например, вместе с клиентом решить, что вместо исправления бага (допустим это один-два дня) лучше сделать важную штуку, которая, по мнению клиента, принесёт больше пользы?


30 апреля 2015

Это похоже на компромисс между качеством и пользой, Михаил: http://artgorbunov.ru/bb/soviet/20150316/

Николай Яковенко
30 апреля 2015

Николай, в том то и вопрос: как не пожертвовав качеством продукта, реализовать его вовремя, если баги ставят под вопрос его качество?


30 апреля 2015

Применить ФФФ, Николай: http://artgorbunov.ru/bureau/fff/

Дмитрий Кайгородов
15 января 2016

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

Неплохо начать с проектов и замечательно выпустить продукт.


Цель рубрики — обсуждение вопросов дизайна всех видов, текста в дизайне и взаимоотношений дизайнеров с клиентами.

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

Решение о публикации принимается один раз; мы не имеем возможности комментировать или пересматривать свое решение, хотя оно может быть ошибочно. Уже опубликованные комментарии могут быть удалены через некоторое время, если без них обсуждение не становится менее ценным или интересным.

Вот такой веб 2.0.

Вы не обязаны соглашаться Как вести документацию по дизайну Как флексить. Перенести на следующую итерацию Как флексить. Не выходить в надсистему




Недавно всплыло

Как написать заказчику, что я установлю модуль на его сайт после окончательной оплаты, и при этом не обидеть его? 2 У меня остаётся ощущение, что я идиот, «рассыпала бобы», но на конкретных ошибках не могу себя поймать 3 1 Это я неправ, что долго думал, или магазин, что допустил такую ситуацию? 3