Уроки двусмысленности
Управление процессом разработки программного обеспечения можно сравнить с выпасом кошек. Другими словами, вы не можете по-настоящему сделать это, но вы обязательно можете попробовать это в старом колледже. Другими словами, программный проект похож на попытку защитить Леброна Джеймса в НБА. Вы не можете остановить его - вы можете только надеяться сдержать его.
Не секрет, что управление разработкой программного проекта - наука неточная. Вот 11 трюизмов, которые я усвоил за эти годы, которые помогли мне понять ограничения нашей способности управлять странным миром проектов разработки программного обеспечения.
1. Оценки всегда неверны
Независимо от того, рассчитываете ли вы что-то за один час или за год, ваша оценка неверна. Просто так оно и есть. Они не обязательно будут ошибаться - они могут быть немного неправильными, но они будут ошибаться.
Если вы посмотрите отчет об ошибке и думаете: «Это займет час, чтобы исправить», это почти наверняка не займет и часа. Это может занять 45 минут, может занять три часа, но шансы, что это займет ровно час - даже плюс-минус минуту или две - невелики. Теперь вы можете вместо этого сказать «около часа». На самом деле это лучшая оценка, потому что фактические точные оценки неверны.
Теперь для коротких проектов, которые могут занять час, это не имеет большого значения. Но…
2. Чем крупнее проект, тем менее точной будет ваша оценка.
Чем больше проект, тем менее точной будет оценка, особенно если эта оценка сделана в самом начале проекта. Как и в случае с оценкой часов, приведенной выше, если вы оцениваете проект в год, это может занять девять или 36 месяцев. В некоторых случаях это может занять пять лет. Невозможно узнать, когда проект только начинается.
Чем масштабнее проект, тем больше «неизвестных неизвестных». Обычно задействовано больше людей. То есть по мере увеличения размера проекта будет происходить все больше переменных и вещей, которых вы не можете предвидеть. Все это добавит времени к проекту, что вы не можете планировать вначале, потому что по определению вы не знаете, что они произойдут.
3. Сосредоточенность и концентрация - наши самые ценные - и самые редкие - товары
При создании программного обеспечения самое ценное, что требуется для завершения проекта, - это способность разработчиков в команде концентрироваться, не отвлекаясь.
Чем меньше отвлекающих факторов, тем продуктивнее будет команда. Это действительно так просто. Одна из основных обязанностей менеджера по разработке программного обеспечения - уменьшить количество и продолжительность отвлекающих факторов для команды.
Разработчики программного обеспечения, если их оставить в покое, могут быть весьма продуктивными. Когда их прерывают - будь то встречи или люди, которые задают вопросы или что-то еще, - они могут очень быстро потерять свою продуктивность. Все мы знаем о «потоке» и о том, как сложно попасть в поток и остаться в нем. Это время истечения подобно золоту и должно быть защищено как таковое.
4. Закон Хофштадтера - это правда
Закон Хофштадтера гласит:
Это всегда занимает больше времени, чем вы ожидаете, даже если принять во внимание закон Хофштадтера. - Википедия
Это связано с оценками, но важно отметить красоту этого афоризма. Вы можете увеличить свои оценки, потому что думаете, что это поможет выиграть время, чтобы добиться цели. Вы можете добавить дополнительные факторы, запланировать «неизвестные неизвестные» и увеличить свои оценки, чтобы учесть уверенность в том, что это займет больше времени, чем вы думаете, но, в конце концов, это почти всегда будет занимать больше времени, чем вы думаете. довести проект до конца.
5. Вы не можете ускорить разработку программного обеспечения, вы можете только ограничить то, насколько вы ее замедляете
Некоторым менеджерам трудно понять этот трюизм. Программное обеспечение займет столько времени, сколько потребуется. Нет никакого способа сделать это быстрее. Вы можете потребовать, чтобы команда потратила больше часов. Вы можете взломать кнут. Вы можете умолять, уговаривать и умолять. Вы можете сказать: «Но это займет всего три месяца!» В конце концов, вы не можете увеличить скорость работы команды разработчиков программного обеспечения в долгосрочной перспективе (то есть в ходе проекта).
Если вы начинаете понимать, что закон Хофштадтера действительно верен, и думаете: «Я могу заставить этих людей работать быстрее», вы ошибаетесь. Все, что вы действительно можете сделать, - это предотвратить их медленную работу, уменьшив отвлекающие факторы и позволив им работать автономно. Это тонкое различие, но очень важное.
6. В минусе можно бегать только очень, очень короткие периоды.
В том же духе вы можете потребовать от команды потратить больше часов, сжечь полуночное масло, приходить по выходным и тому подобное, и вы можете получить некоторую (очень) краткосрочную выгоду. того, что.
Но если вы попытаетесь сделать это нормой - если вы попытаетесь постоянно запускать двигатель своей команды на красной линии оборотов в минуту - вы сожжете двигатель. Вы довольно быстро увидите убывающую отдачу. Люди, как двигатели гоночных автомобилей, не могут длительное время подвергаться перенапряжению без поломки.
7. Время для мозга важнее, чем для секса
Ничто так не снизит производительность, как требование Butt Time (т. Е. Чтобы ваши разработчики часами сидели в своих креслах). Вы можете измерить время прикосновения и почувствовать, что у вас есть показатель, который действительно покажет, насколько продуктивны люди. Но ты ошибаешься. Требование времени на задницу деморализует команду, которая действительно хочет тратить Brain Time.
Brain Time - вот что действительно важно. Подумайте об этом так: допустим, вы менеджер, и для вас очень важно, чтобы ваша команда, сидящая за своими столами, «работала». Вы бродите по офису и видите, как разработчики сидят в креслах и бьют по клавиатуре. С миром все хорошо.
Но потом вы встречаетесь с одним разработчиком, а он просто сидит и смотрит на свой экран. Вот и все. Они сидят и смотрят. Примерно полчаса. Какого черта! Они ничего не делают!
Но, конечно, они есть. Они думают. Они тратят свое мозговое время на решение очень сложной проблемы. Может, они даже встанут и немного побродят по зданию. В конце они садятся, набирают 11 строк кода и отмечают завершение пользовательской истории.
Удовлетворяли ли они вашим критериям «Время задницы»? Нет. Они предложили элегантное решение очень сложной проблемы? да.
Butt Time ничего не доказывает. Brain Time означает все.
8. Оборудование дешевле, чем время разработки - намного дешевле
Разработчики дорогие. Вы платите конкурентоспособную зарплату, чтобы привлечь лучшие таланты. Час их времени стоит недешево. Несмотря на это, многие компании не осознают невероятную ценность часа времени разработчика и экономят на оборудовании для команды.
Но давай, компьютеры дорогие! Эта дополнительная оперативная память сократит бюджет на оборудование!
Что ж, это может привести к потере бюджета, но это потому, что у вас проблемы с бюджетом.
Взгляните на это так: допустим, вы платите разработчику 100 000 долларов в год или около 50 долларов в час. Допустим, они проводят час в день, ожидая, пока компилятор выполнит свою работу. Затем предположим, что вы можете добавить немного оперативной памяти и более быстрый процессор на машину этого разработчика и сократить это время до 45 минут в день. Вы экономите 15 минут в день. При 200 днях в году это 50 часов. При 50 долларах в час это экономия 2500 долларов на разработчика в год. Но что, если дополнительная стоимость более быстрой машины составит 500 долларов?
Вы уловили суть. Если у вас 20 разработчиков, покупка более быстрой машины сэкономит вам 40 000 долларов при инвестициях в 10 000 долларов. Это должно быть понятно.
И это только для более быстрой компиляции. Все остальное, что они делают, также будет быстрее.
Если ваш бюджет не позволяет покупать более быстрые машины, вам необходимо скорректировать бюджет.
9. Вы не можете измерить производительность разработчиков программного обеспечения
Я написал целую статью на эту тему.
Достаточно сказать, что пытаться объективно измерить продуктивность разработчиков - глупое занятие, и к ним не следует прибегать. Есть субъективные способы измерения производительности, но это требует опыта и здравого смысла. Их трудно найти, и они бесценны, если они у вас есть.
10. Если вы не читали «PeopleWare», значит, вы на самом деле не менеджер по разработке программного обеспечения.
Насколько мне известно, есть только одна книга, которая научит вас управлять разработчиками программного обеспечения: Peopleware Тома ДеМарко и Тимоти Листера (обязательно получите третье издание…).
Эта книга отличная, проницательная, по существу, ясная и беспощадная. Он полон мудрости об управлении проектами программного обеспечения и разработчиками программного обеспечения. Это вне времени.
Прочтите это.
11. Качество - это восприятие, а не количество ошибок
Это действительно трудно принять.
Вот основная предпосылка: в вашем трекере ошибок может быть почти ноль ошибок, и люди все равно будут думать, что ваше программное обеспечение содержит ошибки. В вашем трекере ошибок может быть большое количество ошибок, и люди могут подумать, что ваше программное обеспечение надежно, как камень. Нет корреляции между количеством ошибок в вашей системе отслеживания и восприятием качества вашего программного обеспечения.
Я не утверждаю, что вам не следует пытаться сократить количество ошибок - как раз наоборот. Но, в конце концов, ваше программное обеспечение можно назвать высококачественным только в том случае, если ваши клиенты так его воспринимают - а количество ошибок не обязательно будет диктовать это. Странно, да?
И раз уж мы заговорили об этом, что означает «большое» количество ошибок? Что означает «высокий», когда ваша кодовая база состоит из 100 000 строк кода? 5 миллионов строк кода? Что сказать?
Заключение
Внедрение программного проекта для безопасной посадки на короткую взлетно-посадочную полосу - сложное и трудное предложение в самых лучших обстоятельствах. Добавьте к этому двусмысленность и все то, что может пойти не так, как надо, - и чудо, что что-то будет сделано.
Уловка состоит в том, чтобы принять и понять эту двусмысленность и работать с ними, а не против них. Принятие этих 11 трюизмов поможет в этом.
