Почему тебе не нужно идеальное решение

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

В этой статье я объясню, почему тебе не нужно идеальное решение.

Тебе не нужно выделываться на все 100


Стопроцентным не бывает даже спирт. А если бы был, то что? 
Попытка достичь мифических 100% обходится  катастрофически дорого и не приносит ничего, кроме сорванных сроков и косяков везде, где только можно.

По данным The Standish Group, 50% функционала не используется практически никогда, 30% — редко, и только 20% функционала используется часто.

По-научному это называется Закон Парето: 20% усилий приносят 80% результата.

В большинстве случаев 80% результата вполне достаточно. Не стоит переплачивать и рисковать. Сделай хорошо то, что действительно нужно.  

Не надо решать за всех


Эффективное решение — это не обязательно самое правильное решение. Это правильное решение, которое поддерживает команда.

Ты можешь быть бесконечно прав, но какой в этом толк, если в конце дня исполнитель сделает всё по-своему? 

Доктор Роберт Завацки выразил это формулой 

$ED = RD * CD,$

где 
ED (effective desicion) — эффективное решение,
RD (right desicion) — правильное решение,
CD (commitment to decision) — уровень приверженности этому решению.

Поезд не остановится на «поезд, стой, раз, два», а команда не будет вкладываться в решение, в которое не верит, только потому, что ты начальник.
Хочешь результат — получи поддержку команды.

Благими намерениями вымощена дорога в ад


Приходилось слышать  «Ну а что, вам сложно? Мы уже обсуждаем дольше»? В английском это называется gold plating (нанесение позолоты). В итоге маленькая доработка занимает больше времени, чем ожидалось, а на выходе оказывается, что теперь вообще ничего не работает. 

По данным PMI, в 2018 году 52% проектов пострадали от расползания содержания и неконтролируемых изменений. Что характерно, компании-чемпионы страдают от этого намного реже, чем отстающие: 33% против 69%.

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

Как получить хорошее решение


  1. Сделай декомпозицию продукта/требований.
    Разберись, что ты хочешь получить на выходе и не оставляй места для нездоровых фантазий.
  2. Расставь приоритеты между компонентами. Например, для этого подойдет метод Moscow.
    Жизненно необходимым компонентам присваивается значение Must.
    Компонентам, без которых жить можно, хотя не хотелось бы, Should.
    Хотелкам присвойте Could.
    Остальное — это Would или Won’t. Пока можешь о них забыть.
  3. В первую очередь делай компоненты MUST.
    Работающий продукт лучше, чем обещание чуда.
    Остальным займёшься, когда сделаешь работу.
  4. Не хватайся за все гениальные идеи, как сделать еще лучше. Каждую нужно тщательно взвесить.
    Научись говорить Нет/Не сегодня/Я подумаю. Если чья-то хотелка сработает, он окажется героем. Если запорет весь проект- ты будешь крайним.
  5. Всё это делай с командой и привлекай заказчика.
    Если не хочешь завалить проект, считая себя непризнанным поэтом. 

И никогда не забывай: Done is better than perfect.
Поддержать автора
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 28

    +3
    Я разделяю вашу точку зрения, но если бы не разделял, то этой статьей вы бы меня не переубедили.
      0
      Честно говоря, в жизни иногда даже самого себя приходится в этом переубеждать заново.
      Здесь лучший аргумент — собственные ограниченные ресурсы. Ну и опыт, конечно.
      0
      33% против 69% это интересный показатель.
        +1
        Это не из 100%. 33% среди 100% чемпионов, 69% среди 100% отстающих.
        –3
        Стопроцентным не бывает даже спирт

        Бывает, кстати, это т.н. абсолютный спирт. И мне не понравилось, что вы обращаетесь ко мне на «ты». Хотя в целом, безотносительно особенностей написания, в статье есть здравое зерно.
          0
          Не хотел показаться грубым. Писал как себе. Если что, приношу извинения.
            –2
            Да всё в порядке. Честно сказать, я просто немного придираюсь на основе своих тараканов. Пишите еще :)
              +3
              Почему одному человеку говорят «вы»?
                0
                Из вежливости, которая подразумевает, в частности, дистанцию, которую сокращают только по приглашения и взаимному желанию.
                  0
                  Вежливость — понятно, дистанция — понятно, непонятно, как связаны между собой вежливость с дистанцией и «вы». «Вы» означает 2 и более человек. Им нравится это? И почему «ты» — это плохо?
                    0
                    Простите за любопытство, а вы русский язык по книгам изучали или по форумам?
                    0
                    дистанцию, которую сокращают только по приглашения и взаимному желанию

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

                    Понятное дело, что автор конкретной статьи не имел целью оскорбить лично меня, но и я не имел цели оскорбить его своим ответом, я просто выразил свое мнение по поводу статьи — что понравилось, а что нет, так что я искренне не понимаю, откуда минусы.
                      0
                      «Друзья, мы» — понятно.
                      Являешься ли ты «вы»?
                      Мне интересно, как думают люди, кому нравится «вы». Может быть, они знают то, чего я не знаю.
            0
            Предполагается, что будет сделано нужное и в нужном качестве (можно трактовать минимальное и в минимальном качестве), а вылизывать потом, когда продукт взлетит.
            А в реальности этими соображениями могут оправдывать некомпетентность и создание чего то на отвали. Где грань, вот в чем вопрос.
              0
              Некомпетентность, к сожалению, практически все можно оправдать.
              Грань в любом случае искать придётся. Перегиб ни в одну сторону не нужен.
              0
              Что делать с ошибками? На какой стадии проекта писать их обработку?
                0
                Видимо у вас накипело. Некоторые программисты действительно склонны к перфекционизму, особенно фанатеющие от своего дела. Так что брать на проект таких фанатиков нужно очень осторожно и четким пониманием их роли
                  0
                  С юристами-перфекционистами работать тоже очень интересно ;)
                  0

                  Про закон Парето (20/80) — он конечно работает, но загвоздка в том, что усилилий все равно надо затратить 100%

                    0
                    в каком смысле?
                      0
                      20% зависят от остальных 80%
                      Например регистрацией пользуются 1 раз, а авторизацией много раз, но смысла в авторизации без регистрации мало.
                        0
                        Я бы не стал относить регистрацию к 80%.
                        К 80% я бы скорей отнёс скринкаст «как пройти регистрацию» или возможность авторизоваться через Одноклассники.
                        Заказчик может вообще не задумываться о том, что регистрация — это отдельная сущность, но если без неё невозможна авторизация, которая ему нужна, то это must и те самые 20%.
                        0
                        Ссылка из вашей статьи ведет на страничку в Википедии, где эта ситуация объясняется («Критика принципа Парето»). Можно привести в качестве примера строительство дома, где на проект, коммуникации, фундамент и п.р. тратятся огромные ресурсы, но доход приносит только продажа помещений.
                        Кстати, современная разработка софта как раз напоминает ситуацию, когда сначала строим квартирки, а потом пытаемся подвести под них фундамент и коммуникации, хотя идея была сначала поставить бытовки и если в них кто-то поселился, то уже строить нормальный дом.
                          0
                          Думаю, к закону Парето тоже стоит применять закон Парето :)
                          Во всяком случае, применять его механически и доводить до абсурда точно не стоит.
                          Если кто-то продаёт квартиры и не собирается стоить дом, это больше похоже на мошенничество, чем на управленческую проблему.
                          А вот ситуация, когда команда создаёт продукт, но никто не задумывается о продажах, встречается довольно часто. Иногда действительно полезно напомнить, что доход приносит именно продажа и на неё тоже стоит выделять ресурсы.
                      0
                      Чтобы перестать делать идеальное решение, программисту нужно научиться мыслить нуждами бизнеса. Очень часто в бизнесе надо проверить нужно ли что-то вообще кому-то, поэтому разработка идеально работающей функции не имеет смысла, ведь она может оказаться никому не нужна, поэтому следует делать Proof of Concept в виде некоего MVP. Причем этим MVP может быть даже обычная кнопка в уже работающей и запущенной программе.
                      Плюс ко всему, достаточно сложную систему практически невозможно построить сразу с нуля, большинство сложных и хорошо работающих системы возникают, эволюционируя из более простых.
                        0
                        Мотивирует =) Спасибо!
                          0
                          Дополню немного: «Если есть два варианта — лепи чекбокс!» :) Никогда не решай за юзера, ЧТО он может захотеть, всегда давай ему выбор. Особенно если решил «выпилить» старый функционал и «намодернячить» что-то (как тебе кажется) более удобное.

                          Постоянно взаимодействовать с непосредственным юзером. Не его начальником или «властелином всея ИТ», а только с теми, кто непосредственно будет делать работу.

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

                          По поводу команды… спорный вопрос. КАЖДЫЙ из вас — непризнанный гений. Но десять гениев в команде — это просто сборище упрямых баранов, ведущее проект в никуда. Решения должен принимать ОДИН, выслушав мнение остальных. Он же — вести главную разработку. Особенно убивают проект «космические архитекторы», высасывающие из известного пальца маргинальные случаи и превращающие простую задачу в «гиперконфигурируемый всемогутер» примерно на миллион человекочасов. Особенно этим страдает MS.

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

                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                            Самое читаемое