Незавершённость vs кривота

[ermouth]

Цитирую из подзамка:

Бизнес требует всегда оставлять продукт сильно незавершённым. Он выглядит завершённым (или почти завершённым) для потребителя, но он выглядит отвратительно недоделанной какашкой для разработчика. Весь процесс разработки это процесс самообмана, когда для приятной продуктивной работы тебе нужно тешить себя мыслью, будто бы ты всё делаешь правильно, но в конце получится как всегда. Например, создавать длинный backlog низкоприоритетных issues in the bug database - это типичный психологический трюк, позволяющий создать целостность хотя бы в голове. Опытный программист в глубине души понимает, что акт занесения низкоприоритетной задачи в такой список эквивалентен заявлению "это не будет сделано никогда", но при этом ему приятно думать, что оно было учтено и понятно, просто оно отложено в силу наличия более важных и нужных вещей.

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

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

PS. Какие же отвратительные мудаки работают в Супе. Не нашёл во встроенном редакторе кнопки "Цитата" – а она была. Дронов и tritankista – это самое гнусное, что случилось с ЖЖ за всё время его существования.

Comments

[morfizm.livejournal.com]

Утилитарность длинных бэклогов на мой взгляд сильно зависит от того, как они выглядят, и как именно ими пользуются.

Если есть хорошая система каталогизации + поисковая система, позволяющая легко находить дубликаты (и избегать их создания), а также система, позволяющая по компонентам и приоритетом увидеть все items в виде одного большого списка, по задаче на строку, то оно работает неплохо. Я с недавних пор для своих проектов начал создавать Wiki-страницу на внутреннем сайте, в которой несколько секций по приоритетам, задача занимает строку, и в начале строки тэгом в квадратных скобках обозначена компонента. Добавить/удалить задачу - дело на 2 минуты. Просмотр всего списка бегло и в одиночку - минут 5 (можно делать пару раз в неделю), а вдумчиво, с другими team members и с обсуждением приоритета, занимает пару часов, но можно делать один раз в несколько недель (цель - на основе недавнего опыта, вытащить вверх те несколько вещей, которые таки надо сделать, выкинуть сделанное или в чём вообще стопудово отпала надобность и опустить ниже всё остальное).

Всё равно реалии обычно такие, что делается процентов 10-20 от тотального списка, но список помогает выбирать правильные 10-20 процентов, а также помогает избегать повторных обсуждений новых задач - скажем, когда коллега обнаруживает, типа, "а у нас сломано вот здесь" и начинает обсуждать, как это надо чинить. Когда такое повторяется раза четыре это уже непродуктивность, легче сразу оборвать на полуслове, сказав "это уже давно в списке 3-го приоритета".

Ещё - длинный список задач очень помогает бороться с низкоприоритетными ненужными задачами из случайно входящих.
Пример: у тебя список 10 самых важных и нужных задач, тебе приходит человек (или начальник) и придумывает новую. Очевидно, она менее приоритетна, чем эти 10, но почему бы её не сделать в 11-ю очередь?
Имея список ты всегда можешь аргументировать, что она, очевидно, менее важна чем 57-я и все предыдущие, и радостно вписываешь её на 58-е место, отправляя человека с чувством удовлетворения, что его issue учтён, посчитан, и "когда-нибудь будет сделан", конечно же, если к тому времени уже будут сделаны все более приоритетные вещи ;)

[ermouth.livejournal.com]

Обрати внимание, что ты описываешь, в сущности, вконтактовскую стену плюс теги ЖЖ плюс группировку в наборы типа блокнотов эверноута плюс таск менеджер (выставление на некоторые посты даты готовности).

Такого рода функционал – это не только бэклог. Под эту схему вписывается вообще большинство внутренних бизнес-коммуникаций.

У меня оно именно так и реализовано. То-есть нет какого-то специального бэклога там, или таск-менеджера, или внутренней вики – есть просто стена, которая успешно все эти функции выполняет сразу по всем проектам.