Как объяснить нетехническому человеку, почему задача займет намного больше времени, чем они думают? [закрыто]

Почти каждый разработчик должен ответить на вопросы со стороны бизнеса, такие как:
Почему понадобится 2 дня, чтобы добавить эту простую контактную форму?

Когда разработчик оценивает эту задачу, он может разделить ее на этапы:

• внести некоторые изменения в базу данных
• оптимизировать изменения БД по скорости
• добавить внешний конец HTML
• написать код на стороне сервера
• добавить проверку
• добавить клиентский JavaScript
• использовать юнит-тесты
• убедитесь, что настройка SEO работает
• внедрить подтверждение по электронной почте
• рефакторинг и оптимизация кода для скорости
• ...

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

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

Вы только что сделали это в своем вопросе.

Разделите задачу на отдельные этапы и дайте оценки для каждого. Это покажет, что вы рассмотрели все варианты и (надеюсь) рассмотрели все возможные варианты.

Если сроки слишком велики, вы можете обсудить, какие части (например, подтверждение по электронной почте) не нужны в этом случае с конкретными данными, а не просто пытаться втиснуть кварту в пинту.

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

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

Но вы могли бы потерять управление проектами из-за слова «БД», если бы не слово «оптимизировать».

Я обычно выражаю эти вещи управлению проектами в терминах БОЛЬШИХ шагов со словами, которые описывают риск с точки зрения бизнеса. Если взять твой список, я бы свел его к следующему, если бы говорил с менеджментом моего проекта:

1. Во-первых, есть две части: веб-страница, которую видит пользователь, и сервер, который выполняет тяжелую работу. Обе части должны быть там, чтобы эта функция работала.
2. Первая часть будет посвящена созданию веб-страницы, которая имеет смысл для пользователя (добавьте внешний интерфейс HTML, добавьте JavaScript на стороне клиента). Ключевым моментом здесь является то, что веб-страница должна выглядеть так, как будто она является частью этого продукта, она должна работать во всех поддерживаемых нами браузерах и должна быть удобной. Это то, что видит пользователь, поэтому, если он будет выглядеть плохо, он будет думать, что наш продукт плохой. На разработку и последующее тестирование уйдет X дней.
3. Далее, под веб-страницей должен быть материал, выполняющий эту работу. В данном случае это означает, что здесь нужно вставить описание функции (сопоставить - внести некоторые изменения в базу данных, написать код на стороне сервера, выполнить подтверждение по электронной почте, добавить проверку, использовать модульные тесты). Я не могу просто бросить это вместе. Если код разработан и затем протестирован, мы рискуем нанести ущерб данным ВСЕХ пользователей. Это означает, что простая новая вещь может повредить репутации продукта по всем направлениям - даже для пользователей, которые не используют эту особую функцию. Наши методы разработки охватывают это - мы проводим множество тестов, чтобы убедиться, что этого не произойдет, - но это означает, что мне нужно планировать время, чтобы протестировать его должным образом. Это займет у меня Y дней.
4. Скорость имеет большое значение в нашем продукте. Если вещи не происходят быстро, пользователи будут думать, что продукт не годится. Поэтому после того, как я напишу все эти вещи, мне нужно будет пройти работу и убедиться, что она соответствует стандартам производительности. Это большая проблема в веб-вещах - если люди увидят, что сайт работает медленно, они быстро переключатся на другой продукт для удовлетворения той же потребности, потому что действительно трудно увидеть разницу между медленным и сломанным. Такая работа обычно занимает Z дней (оптимизируйте изменения БД по скорости, реорганизуйте и оптимизируйте код по скорости)

Я бы избежал любой оценки, которая составляет менее половины дня. На каком-то уровне им придется поверить, что вы знаете, о чем говорите. И если они действительно думают, что это будет только 2 часа, то предложите им посидеть с вами в течение 2 часов, пока вы будете рассказывать, как именно они выглядят в течение двух часов в жизни разработчика ПО, - тогда сделайте класс кодирования 101 для около 2 часов, чтобы показать, что именно нужно учитывать, чтобы даже начать решать проблему.

Наиболее важными являются следующие вещи:

• Если вы больше говорите о восприятии клиента и использовании продукта, то вы частично говорите на его языке - языке $$ - дело в том, что если код будет взломан ненадежным способом, вы в конечном итоге потеряете бизнес - если нет на этой функции, затем на некоторой последующей функции, когда плохие методы разработки сделали невозможным расширение кода.
• Изложите последовательность событий. Следующий нетехнический вопрос будет звучать так: «Если бы у нас было больше разработчиков, чем у вас, произойдет ли это быстрее? Если это так, если на это уйдет 40 часов, смогут ли 40 человек сделать это сегодня днем?» Ответ, конечно же, «НЕТ! ВЫ ВЫ НЕ СУЩЕСТВУЕТЕ?». Но это не самый лучший. Самое лучшее, что здесь есть логическая последовательность шагов. Вещь B не может быть выполнена до тех пор, пока не будет создана вещь A (если вы не написали какой-либо код, вы не сможете его оптимизировать или протестировать ...). Вещи А и А 'могут быть выполнены вместе, поэтому, если бы они могли сэкономить этого умного парня там, вы могли бы сократить время с недели до 4 дней, и если бы они могли гарантировать отличную поддержку тестирования, то вы, вероятно, могли бы добраться до 3 дня. Там'
• Сосредоточьтесь на риске и будьте готовы сказать, что некоторые риски того стоят. Это то, за что деловым парням платят большие деньги - выяснение того, какие риски стоят того. Например, если скорость выхода на рынок приводит к снижению производительности, поскольку у вашей компании достаточно наличных денег для создания смешного количества серверов в краткосрочной перспективе, то вам может быть предложено пропустить все это на шаге 4 (оптимизация кода / базы данных). ). Это их право - ваша задача - объяснить риски, связанные с этим решением.
• Однако, если вы не доверяете этим людям, получите письменное подтверждение - оно не должно быть конфронтационным, просто быстрое электронное письмо с надписью «вот что, я думаю, мы обсуждали, вот что я не делаю, вот риск. Я собираюсь сделать это сейчас, так что дайте мне знать, если вы не согласны ... если я не получу известие от вас, я подумаю, что это правильный путь для продолжения ". Учитывая, что управление продуктами может стать центром краткосрочной потери памяти, это очень полезно для всех.

Есть поговорка: «Нельзя помещать десять фунтов (дерьмо) в пятифунтовую сумку». Ваша задача - показать, что задание стоит десять фунтов, и они просят его выполнить в пять фунтов.

Единственное, чего вам не хватает - это оценки времени. Поставьте оценку времени для каждой задачи и покажите, как все эти вещи складываются вместе с оценкой, которую вы предоставляете. Не допускайте, чтобы какая-либо оценка превышала 4 часа. Если у вас есть какое-либо задание, в котором вы говорите «день» или «10 часов», разбейте его на более мелкие подзадачи.

2h make some changes to Database
2h add front end HTML
   write server side code
     4h input validation
     4h database inserts
2h add validation
2h add client side javascript
   use unit tests
     2h client-side tests
     3h server-side tests
2h make sure SEO is setup is working
2h implement email confirmation
2h optimize DB changes for speed
2h refactor and optimize the code for speed

Теперь у вас есть подробный счет расходов. В общей сложности до 27 часов работы.

Теперь вы можете показать это своему клиенту и сказать: «Это то, что должно быть сделано, со стоимостью каждого». Используйте слово «стоимость», потому что время - это стоимость, а руководство понимает затраты. Объясните, что вы могли бы в конце концов отбросить две задачи оптимизации, но они будут иметь отрицательный эффект в будущем, и они составляют только 15% от общей оценки.

Также убедитесь, что вы объясните, каковы ваши часы / день, реально. Например, если вам требуется техническая поддержка, поддержка баз данных или что-то еще, включите это в свою оценку. Не говорите «Ну, я могу делать 7,5 часов в день хорошего кодирования», потому что вы, вероятно, не можете. Это, вероятно, больше похоже на 5 или 6.

Затем, самое главное, отслеживать ваши успехи. Скажем, что вы можете делать 5 часов в день кодирования. Затем вы сможете выполнить первые две задачи (в моем примере) в понедельник, закончить третье и начать четвертое во вторник и так далее. Составьте контрольный список, который показывает это, чтобы вы могли показать их в среду, когда они придут, и сказать: «Как дела, вы все еще собираетесь сделать к концу пятницы?»

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

Спросите их:

Как бы вы это сделали? Какие модули вы бы поменяли? Сколько строк кода? Каковы последствия для безопасности? Какие-либо изменения в схеме базы данных? Если вы внесете какие-либо изменения в БД, сколько файлов будет затронуто? Сколько времени понадобилось, чтобы добавить последнюю форму? Каково среднее (среднее арифметическое) для добавления формы? Какой был самый длинный? Я предполагаю, что это займет одну минуту меньше, чем самый длинный. Если вы не знаете, сколько времени потребовалось для добавления последних N форм, то эта оценка гарантированно будет точной только на один порядок.

Я мог бы сказать вам, чтобы объяснить им, что их программное обеспечение похоже на 100-тонную машину с 10 000 различных частей, большая часть которых связана сложным образом. Установка 1-дюймовой детали в эту машину требует некоторой разработки, чтобы она не сломалась, НО лучший ответ:

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

Как и в 20-м веке, чтобы накопить хорошую архитектуру и инженерные решения для строительства больших зданий, инструменты для разработки программного обеспечения просто не получили широкого распространения. Они разрабатываются: это требует нового мышления. См. Zen Code на wiki.hackerspaces.org/Hacking_with_the_Tao.