68. 5 самых сложных проблем разработки софта

Разработка софта вообще дело не особенно простое. Как любое непростое дело, оно имеет несколько самых сложных областей, в которых мало кто что-то понимает (хотя многие делают вид). Не надейтесь на глубину в этом посте, после 6 часов собраний просто невозможно написать ничего глубже футбольной речевки. Так что только нытье и никаких решений.

5. Как измерять удовлетворенность пользователей?

Вот работаем мы работаем, пишем программы, которыми пользуются люди, и не знаем, насколько они всем этим довольны. Насколько хорошо наш продукт решает проблемы пользователей? Сколько лет жизни мы отняли, загружая диалоговое окно 5 секунд, вместо одной? Сколько нервных клеток совершило апоптоз во время даунтаймов? Сколько положительных эмоций мы вызвали, добавив emoji в навигационное меню? Пользователи любят наш продукт или ненавидят?

К сожалению пока никто не может ответить на эти вопросы. Многие пытаются использовать Net Promoter Score, но эта штука работает довольно посредственно. На вопрос “How likely would you be to recommend Targetprocess to a friend or colleague from 1 to 10?” порой отвечают “Вы рехнулись? Я не говорю с друзьями о таких вещах”.

NPS в действии.

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

А если вы работаете в аутсорсе? Часто вы получаете фидбек от пользователей? Насколько они довольны? И как вообще жить, если не чувствовать пользы?

4. Как дробить работу?

Практически любой разработчик стремится взять большую задачу и сделать её целиком, не разбивая на мелкие. Это можно понять, потому что мелкие задачи увеличивают transaction cost. Каждую нужно стартануть, протестировать, пройти код ревью и выпустить в продакшн. Не лучше ли взять задачу и спокойно делать её целый месяц? Как показывает практика, обычно не лучше. Конечно, бывают сложные и глубокие задачи, требующие огромного фокуса и длительных сроков, но мало. Обычно работу лучше дробить.

Об этом пишут практически везде, но в реальности внедрить эту практику оказывается невероятно сложно. Такое ощущение, что она просто не способна войти в привычку и постоянно деградирует, если отвлечься и перестать обращать на нее внимание.

3. Как не переписывать систему каждые несколько лет?

Любой продукт, который не помер в первые пару лет, будет переписан. Это чертов закон продуктовой разработки. Targetprocess был полностью переписан один раз и наполовину во второй (и очень жаль что мы не переписали тогда вторую половину). Книга Coders at Work изобилует историями о переписываниях. Кажется, ничего невозможно сделать нормально с первого раза.

Конечно, это можно объяснить. Первая система пишется на прорыв, чтобы проверить гипотезу и рынок. Ну на самом деле, чего вкладываться в идеальный код и архитектуру, если сама система нахер никому не нужна? Вот проверим её нужность, тогда можно спокойно все сделать круто. Но фиг там. В этом момент вас настигает синдром второй системы, после которого либо продукт все же загибается, либо воскрешается птицей-феникс посредством третьего переписывания.

Ну а дальше технологические революции, которые рано или поздно понуждают компанию к четвертому переписыванию.

Мы так и не научились делать эволюционные архитектуры.

2. Как оценивать работу хотя бы с 80% точностью?

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

Опытные разработчики что-то знаю от жизни

Очевидно, можно достигнуть приемлемой точности оценок, но только ценой неприемлемых временных затрат. Мало кто это понимает, и оценки требуют сделать примерно за 10 минут (я не исключение!). В лучшем случае дают день. В идеальном случае — два дня. Приличная точность может получиться, если для оценки выделить примерно 10% от времени всего проекта. Но если такое сказать любому менеджеру, он посчитает тебя сумасшедшим и уйдет к другим разработчикам за “оценкой в 10 минут”.

1. Как приоритизировать фичи?

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

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

Мы пытаемся использовать какие-то простые модели (Kano), какие-то странные модели (WSJF) и какие-то линейные модели с коэффициентами. Все это работает довольно плохо, и по качеству может сравниться (или проиграть) интуиции опытного продуктового менеджера.

Весьма печально, что на данном этапе развития вся индустрия разработки вынуждена полагаться на black box в голове PO. Потому что интроспекции нет, объяснить ни черта невозможно и приходится убеждать для начала самого себя, а потом и всех окружающих, что твоя интуиция выдала правильный roadmap на следующий квартал.

Так и живем.