Сегодня я расскажу о том, что происходит в головах разработчиков программного обеспечения в тот момент, когда они делают предварительные расчеты; о том, почему им так сложно уловить все идеи в голове; а также как я лично для себя решил эту ситуацию, научился жить и писать софт (для счастливых владельцев бизнеса), но уверен, что мои собственные оценки трудоемкости как никогда ненадежны.
Но сначала история.
Это было когда я был молодым разработчиком (1).
В колледже я преуспел в занятиях по программированию, будучи младшим разработчиком, я мог взломать код и решить любую поставленную передо мной задачу быстрее, чем кто-либо ожидал.
В течение выходных я мог выучить новый язык и продуктивно работать на нем (по крайней мере, я так думал в то время).
Таким образом, как и должно было случиться, у меня появился свой проект. Менеджер по работе с клиентами в общих чертах объяснил мне, чего хочет клиент, мы обсудили это, и я сказал: «Эта работа займет 3 недели».
«Хорошо», — ответил он.
И вот я начал программировать.
Как вы думаете, сколько времени мне понадобилось, чтобы завершить этот проект? Четыре недели? Может быть, пять? Хм, вообще-то: три месяца.
У меня остались четкие воспоминания о том времени — моя самооценка была тесно связана с ощущением, что я «хороший программист», в чем я очень разочаровался.
Я потерял сон и случались небольшие приступы паники.
И этому не было конца.
Я помню чувство в животе, когда разговаривал с тем менеджером, я снова и снова объяснял, что мне пока нечего ему показать.
В один из таких мрачных периодов я решил, что никогда больше не буду совершать подобных ошибок.
К сожалению, за свою карьеру я усвоил кое-что очень трудное: я постоянно совершаю подобные ошибки.
На самом деле я узнал кое-что еще лучше: мы все совершаем эти ошибки.
Недавно я прочитал книгу Дэниела Канемана « Мышление быстрое и медленное представляет собой обширное исследование того, что психология знает о человеческих когнитивных процессах, их удивительных сильных и (на удивление предсказуемых) слабостях.
Моя любимая часть касается уверенности в себе.
Это показало, скажем так, некоторую связь с тем, как разработчики производят расчеты.
Почему ваши расчеты неверны.
Часть I. Написание программного обеспечения = знание чего-то, чего вы еще не знаете Начнем с того, что я считаю, что на самом деле есть только две причины, почему наши расчеты настолько плохи.
Первая причина в каком-то смысле неулучшаема: написание программного обеспечения — это процесс, в котором вам нужно придумать, как описать что-то с невероятной точностью, чтобы вы могли сказать компьютеру, как это сделать.
А проблема в том, что в тех частях, которые вы не до конца понимаете на начальном этапе работы, есть скрытые трудности, которые вылезут наружу и сильно вас заебут. И оно совершенно никаким улучшениям не поддается.
И только если вы действительно «полностью понимаете, что делать» или у вас есть библиотека или программа, которая может сделать это за вас, тогда ничего не пишите.
В противном случае появляется неизвестность, и зачастую она взрывается.
И на решение этих задач может уйти черт знает сколько времени, может быть, один день, один год, а может быть, вам не хватит времени до тепловой смерти Вселенной.
Например, в случае, когда выяснится, что некоторые из задействованных разработчиков ненадежны.
тогда придется переписать весь массив, содержащий ошибки; или, когда база данных не понимает некоторые важные части кодировки.
тогда вам придется перестраивать все ваши схемы с нуля; или, настоящая классика жанра, когда ты показываешь свою работу клиентам, а они не принимают то, что сами заказали, а хотят чего-то немного другого.
чего-то, что сделать гораздо сложнее.
Когда впервые сталкиваешься с такой трудностью, думаешь: «Отныне мне следует быть внимательнее на этапе спецификации».
Но это не очень хорошая идея.
Почему? Основная причина в том, что, как видно из приведенных выше примеров, если вы напишете спецификацию настолько подробно, что учтете все эти непредвиденные обстоятельства, то получится, что вы на самом деле пишете программное обеспечение.
И действительно, нет никакого способа решить эту проблему (если, читая эту статью, вы пытаетесь оспорить это утверждение, то я вам скажу - абсолютно-абсолютно, нет способа.
Полные спецификации - это утопическая экономическая идея Ниже я покажу вам более выгодные, с экономической точки зрения, варианты).
Но вот тут-то и начинается самое интересное.
Каждый программист, проработавший в реальном мире более пары месяцев, сталкивался с описанными выше проблемами.
И все же.
мы продолжаем делать такие поразительно плохие расчеты.
И что еще хуже, мы верим собственным расчетам.
Я сам верю своим, в тот момент, когда их делаю.
Итак, подождите, что я предполагаю, что все разработчики каким-то образом станут жертвами одних и тех же предсказуемых ошибок в мышлении? Да, это именно то, что я предлагаю.
Почему ваши расчеты неверны.
Часть II: чрезмерная самоуверенность Канеман довольно много говорит о проблеме «экспертов», делающих прогнозы.
В поразительно широком спектре ситуаций эти предсказания оказываются совершенно бесполезными.
В частности, следующие три утверждения верны во многих и многих ситуациях:
1- Прогнозы «экспертов» о любых будущих событиях настолько ненадежны, что по сути бессмысленны;
2- Однако обсуждаемые эксперты невероятно уверены в точности своих прогнозов;
3- И самое приятное: кажется, что абсолютно ничто не может уменьшить это чувство уверенности в себе экспертов;
И последнее заявление, которое поистине примечательно, заключается в том, что даже если эксперты пытаются честно признать свои неудачи, даже если они глубоко осознают этот недостаток человеческого мышления.
они, тем не менее, остаются глубоко уверены в точности своих прогнозов.
Вот как Канеман объясняет это после этой истории удивительная история о собственных неудачах на этом поприще: «Уверенность, которую вы почувствуете в своих будущих суждениях, не будет уменьшена тем, что вы сейчас прочитали, даже если вы поверили каждому слову».
Что интересно, есть ситуации, для которых прогнозы экспертов весьма хороши, и ниже я собираюсь продемонстрировать эти ситуации, а также то, как их использовать для улучшения процессов разработки.
Но прежде чем я это сделаю, я хотел бы остановиться на некоторых деталях того, как работает предвзятость самоуверенности.
На практике вы, возможно, сможете обнаружить ее у себя.
Каково это — чувствовать себя неправым: системы I и II и проблема 3 недель и 3 месяцев
В книге «Думай быстро и медленно» Канеман объясняет большую часть психологии как взаимодействие между двумя «системами», которые контролируют наши мысли: Системой I и Системой II. Я бы очень кратко изложил это так: «Система II отвечает за осторожное, рациональное, аналитическое мышление, а Система I отвечает за быстрое, эвристическое и сравнительное мышление».
И самое главное заключается в том, что эволюция, похоже, создала все для одной цели – чтобы Системе II не приходилось делать слишком много.
Что очень логично, с эволюционной точки зрения — Система II медленна, как патока, и невероятно дорога, ее следует использовать в очень и очень редких случаях.
Но вы видите проблемы, без сомнения, без особых раздумий, тогда откуда вашему разуму знать, когда запускать Систему II? С этой точки зрения многие из различных «когнитивных искажений» психологии можно рассматривать как сложные инженерные решения жестокой жизненной проблемы распределения внимания в реальном времени.
Чтобы увидеть, как взаимодействие Систем I и II может привести к поистине ужасным, но честным расчетам, я собираюсь на минутку передать микрофон моему другу (и коллеге по Hut8Labs) Дмунду Йоргенсену ( Эдмунд Йоргенсен ).
В своем письме он описал мне это так: «Когда я спросил себя: «Сколько времени займет этот проект», Система понятия не имела, но хотела получить ответ, поэтому она перекодировала вопрос.
Что? Я подозреваю, что это было что-то вроде «насколько я уверен, что смогу сделать это», и это, в свою очередь, было перекодировано во время каким-то относительным фактором (например, когда Боб чувствует степень уверенности X, тогда он всегда отвечает 3 недели; когда Сьюзи чувствует степень уверенности Х, то она всегда отвечает 5 недель).
Поднимите руку, если вы постепенно поняли, что у вас есть два «больших» измерителя времени? Например, для меня это «3 недели» и «3 месяца».
Первый подразумевает, что «это кажется трудным, но, по сути, я думаю, что знаю, как это сделать»; второй подразумевает: «Ух ты, это сложно, я не совсем уверен, что для этого потребуется, но держу пари, что смогу разобраться».
Ага, я думаю, что Дмунд совершенно прав.
(Для тех, кто откладывает дела дома: мои «3-недельные» проекты, очевидно, займут 5-15 недель, мои «3-месячные» проекты обычно занимают 1-3 года, в тех редких случаях, когда кто-то хочет мне за это заплатить).
Большой! А теперь давайте перестанем быть такими дерзкими!
Вы можете подумать: «Хорошо, я понимаю, к чему ты клонишь, Дэн, нам нужно подойти к этим расчетам в соответствии с принципами Системы II, а не Системы I. Таким образом, наш осторожный аналитический ум будет делать более качественные расчеты».
Поздравляем, вы только что изобрели водопад.
По сути, он использует подход «получите полную спецификацию, прежде чем писать код»: не позволяйте вашей команде делать интуитивные расчеты, заставляйте всех тщательно мобилизовать свои аналитические навыки и подходить к проблеме с подробной спецификацией и расчетами, разбитыми на более мелкие части.
Однако и это обречено на провал.
По-прежнему… Настоящей проблемой здесь является взаимодействие между двумя источниками ошибок измерения: человеческой ошибкой, связанной с чрезмерной самоуверенностью, и неотъемлемым элементом неопределенности, присущим каждому реальному программному проекту.
Эта неопределенность настолько серьезна, что даже аккуратная и рациональная Система II не может дать точные прогнозы.
К счастью, есть способ сочетать использование сильных сторон вашего мышления и в то же время справляться с нестабильностью реального мира.
Во-первых, как использовать сильные стороны своего мышления.
Когда эксперты правы и как это использовать в своих целях
Канеман и другие исследователи смогли выявить ситуации, в которых суждения экспертов не были полностью ошибочными.По его словам: «Чтобы узнать, можете ли вы доверять определенному интуитивному суждению, вам нужно задать два вопроса: достаточно ли постоянна среда, в которой происходит суждение, чтобы делать прогнозы на основе имеющихся данных? Ответ «да» для диагностики и «нет» для подборщика акций.
Обладают ли профессионалы необходимыми возможностями для изучения сигналов и закономерностейЭ» «Соответствующая возможность» означает большое количество сделанных прогнозов, а также тесную обратную связь для изучения их точности.
Проекты разработки программного обеспечения сроком от 6 до 18 месяцев вообще не соответствуют всем этим критериям.
Как я уже говорил ранее, окружающая среда не совсем «постоянна».
Кроме того, у экспертов нет возможности делать множество прогнозов и получать быструю обратную связь.
Если на что-то уходит год и больше, то обратная связь слишком длинная, чтобы тренировать интуицию (плюс понадобится большое количество примеров).
Однако есть подходящая для разработки программного обеспечения форма расчета — задачи на 0–12 часов, если они затем немедленно реализуются.
С этой точки зрения все работает по-другому:
- Хотя случайности по-прежнему много (подробнее об этом см.
ниже), остается надежда на «последовательность окружающей среды».
Два двухчасовых задания имеют гораздо больше общего, чем два шестимесячных проекта;
- Вы можете рассчитывать на сотни подобных вычислений в течение нескольких лет;
- Вы получаете очень быструю обратную связь о точности выполненных расчетов.
).
Рассчитали мы их очень быстро и как-то хаотично – даже не применив для этого педантичные приемы Покерное планирование .
С этой точки зрения вы пользуетесь преимуществами Системы I: она поддается обучению, имеет множество примеров и значимые модели, которые можно использовать.
А благодаря коротким периодам спринтов вы очень быстро получаете обратную связь о качестве ваших расчетов.
Стоп, стоп, стоп! Давайте просто сделаем тысячу 4-часовых вычислений!
Как я могу сказать, что вы можете делать эти микрорасчеты, но почему-то не можете применить их к расчетам на 6–18 месяцев? Разве значения ошибок не усреднены?
По сути, хотя я считаю, что расчеты по этим шкалам обычно верны, в противном случае просто нет предела тому, насколько они могут быть ошибочными.
С математической точки зрения я подозреваю, что фактическое время подчиняется степенному закону распределения.
А степенные распределения известны тем, что не имеют стабильного значения и имеют бесконечную дисперсию, что, честно говоря, мне кажется похожим на те же расчеты проекта большого водопада.
Вы можете подумать: как вообще возможно, что то, что можно сделать за 4 часа, может занять месяц или два? Такое происходит постоянно: вы собираетесь перейти к финальному этапу, но вдруг обнаруживаете, что какие-то скрытые препятствия кардинально меняют все.
Например, при недавнем запуске, пытаясь исправить определенные ошибки в системе, мы решили поставить балансировщик нагрузки перед написанным нами IMAP-сервером.
Чтобы при падении одного сервера балансировщик плавно передавал процессы на другой, и клиенты ничего не чувствовали.
И нам это показалось задачей на 4 часа.
Но когда мы пришли на сайт, мы поняли/вспомнили, что IMAP-сервер использует состояние соединения, в отличие от HTTP-серверов, к которым мы так привыкли.
Получается, что если мы хотим, чтобы переключение на резервный сервер происходило в прозрачном режиме, нам придется управлять состоянием соединения на двух серверах или написать что-то вроде прокси-балансировщика нагрузки, который бы отвечал за состояние соединения и был установлен в перед сервером IMAP.
Нам показалось, что это трехмесячный проект (2).
Вот еще одна причина, по которой короткие спринты играют ключевую роль во всем этом: они накладывают жесткие ограничения на стоимость ужасно неправильных расчетов.
Мы совсем облажались?
так что нам делать? Примите тот факт, что все наши проекты обречены на провал; что мы испортим отношения с другими клиентами, потому что не сможем выполнить свои обещания?
Ответ заключается в том, чтобы сначала признать тот факт, что проведение точных долгосрочных оценок принципиально невозможно.
Как только вы это поймете, вы сможете перейти к следующей задаче, которую довольно сложно решить: как заставить свою команду разработчиков выдавать тонны значений, даже если вы не можете производить какие-либо значимые долгосрочные расчеты.
То, к чему мы пришли, по сути, является объяснением основных принципов того, почему мир принял различные методологии разработки Agile. Подробнее об этом я расскажу в следующей теме: «Сроков реализации проектов нет! Как заставить клиентов полюбить вас, даже если вы не выполняете свои обязательства».
1. (группа играл по радио и все обсуждали .
2. Если вы думаете: «Подожди, а как насчет трех месяцев, как в одном из твоих трехмесячных расчетовЭ», то я понятия не имею, о чем вы вообще говорите.
Перевод осуществлялся в рамках стартап-школы Tolstoy Summer Camp. Теги: #программирование #оценка времени #оценка трудозатрат #управление проектами #agile #lean #startup #tsc #занимаюсь пиаром
-
У Вэй
19 Dec, 24 -
Строка Google Wave В Профиле
19 Dec, 24 -
Разместите Свой Отчет На Techdays.ru
19 Dec, 24
