De lege ferenda
В этом посте я хотел бы систематизировать основные умозрительные «законы подлости», применимые к разработке ПО и управлению этой разработкой.
Закон Паркинсона
Самый известный закон разработки.
Работа занимает всё отведённое на неё время.
Сам Сирил Паркинсон приводит пример со своей родственницей, заполняющей пригласительные открытки. Что если ей выделить день на эту манипуляцию, она будет неспешно делать её весь день, несмотря на то, что работы там на два часа.
Следствие из закона Паркинсона:
Если не установить дедлайн, работа будет продолжаться бесконечно.
Я с этим следствием не согласен. Лично мне комфортнее работается без дедлайна. Логика такая: если всё равно, когда делать задачу и никто меня не торопит, почему бы не сделать её прямо сейчас, чтобы потом отдохнуть? Но в практической разработке, конечно, дедлайны необходимы. Причём, если сделать дедлайн слишком близким, основываясь на законе Паркинсона, вы ничего не добъётесь, команда торжественно пролюбит этот дедлайн.
Закон Хофштадтера
Любое дело всегда длится дольше, чем ожидается, даже если при планировании учесть закон Хофштадтера.
В разработке есть такая распространённая штука как паддинг. Разраб закладывает риски и называет четыре часа вместо двух. Тимлид закладывает риски и закладывает шесть часов, вместо четырёх. Пиэм, зная этих двоих, закладывает риски и называет заказчику двенадцать часов, вместо шести. А прикол в том, что за двенадцать часов они не успеют.
С паддингом можно бороться, прося «положить» риски отдельной строкой. Но картину это не улучшает, команда всё равно, опоздает, как бы вы ни перезакладывались. Чем больше исполнителей у задачи, чем больше зависимостей и чем больше начальников в иерархии, тем больше будет опоздание.
Эти два закона объясняют, почему точно планировать в айти так сложно. И у этой проблемы нет чёткого решения, надо практиковать, долго работать с одной командой, калибруя её, развивать интуицию.
Закон Брукса
Добавление людей в проект на поздних этапах замедляет его выполнение.
Сейчас высшее образование для айтишников считается лишним, но на первом курсе, на экономике рассказывают пример с небольшим магазином и наращиванием количества продавцов. Если добавить к одному продавцу второго, продажи удвоятся. Но если добавить третьего, они не утроятся, эффект будет слабее. А если добавить четвёртого, они могут и снизиться, потому что четыре продавца за небольшим прилавком будут устраивать давку и мешать друг другу.
С разрабами всё ещё сложнее. Им надо довольно продолжительное время въезжать в проект, чтобы начать приносить какую-то пользу. Сколько раз такое было:
— Проект опаздывает, что будешь делать?
— Дайте мне ещё двух сеньоров, мы ускоримся.
Да, ты понимаешь, что производительность не сильно увеличится, но хотя бы на 10-20 % должна возрасти. А команда начинает работать медленнее.
Закон Конвея
Организации проектируют системы, которые копируют структуру коммуникаций в этих организациях.
Если в двух словах, если у вас в компании бардак, не выстроены процессы, не распределены зоны ответственности, не налажена коммуникация между отделами, в продукте тоже будет бардак.
Очень часто вам нужны не крутые разработческие фреймворки, а нормальная оргструктура и базовый менеджмент. Я раскрываю этот аспект в правилах жизни.
Особенно критичен момент с общением между разными продуктами, если вы работаете над комплексом ПО. Если эта коммуникация не налажена, «на стыках» будет огромное количество ошибок.
Закон Каннингема
Лучший способ найти правильный ответ в интернете — не задать вопрос, а разместить заведомо неправильное утверждение.
Дальше будет самоцитата:
Если вам нужно узнать, как в системе А сделать манипуляцию Б и вы хотите обратиться с этим вопросом в комьюнити, не пишите: «Как в А сделать Б?». Напишите лучше: «Какое же говно А, ведь в нём никак нельзя сделать Б!» Если в первом случае вы рискуете остаться без ответа вообще, во втором, скорее всего, ответ быстро напишут.
Неправильное утверждение более иезуитское. Не стоит забывать, что его могут нагуглить другие страждущие, не углубиться в комменты и наделать глупостей. В общем, применяя этот закон в чистом виде, вы вредите сообществу. Но он работает.
Внутри компании тоже работает. Если вы не знаете, как сделать какой-то отчёт, инструкции и примера нет, не спрашивайте, как его сделать, сделайте, как вам будет удобно (до завершения срока, чтобы было время поправить) и покажите руководству или более опытным коллегам, они тут же отгрузят вам конструктивные правки.
Закон Старджона
90 процентов чего угодно — ерунда.
Все знают закон Парето про распределение 80 на 20. Закон Старджона более радикальная версия этого распределения и он более точно характеризует разработку ПО и сами программные продукты.
Дело в том, что 90 % фич, которые приносит ваш продакт — ерунда. Ими будут пользоваться буквально единицы представителей ЦА. Прибыль будут приносить несколько функций, причём не факт, что их будут изначально считать самыми ценными.
Например, даже в весьма приличном раннем ВК было множество функций, но большинство туда заходило слушать музыку и изредка перекинуться парой сообщений с друзьями, не пользующимися аськой. Сейчас Яндекс.Музыка намного интереснее в плане музыки, а общаться в ВК стало просто небезопасно, но наверняка распределение сохраняется.
В плане контента такая же петрушка. На этом сайте 345 статей разной степени качества и полезности, но большая часть трафика приходится на восемь, максимум, десять постов. И это нормально.
Закон Завински
Любая программа стремится расширяться до тех пор, пока не научится отправлять электронную почту. Те программы, которые нельзя расширить, заменяются теми, которые расширить можно.
Сейчас, наверное, отправку электронной почты стоит заменить на свою версию Чат ЖПТ. Ну и сраные сторисы везде, в любом продукте.
Я раскрыл эту тему в посте об универсальных инструментах.
Если кратко, софт переусложняется фичами до тех пор, пока пользоваться им новичку не станет совершенно невозможно.
Закон Хайрама
При достаточно большом количестве пользователей API становится неважно, что вы обещали в контракте: кто-нибудь обязательно будет зависеть от всего наблюдаемого поведения вашей системы.
Прикол в том, что если вы попытаетесь избавиться хотя бы от чего-то, составляющего 90 % ерунды в вашем продукте, тут же поднимется вой от трёх с половиной пользователей, которые эту ерунду использовали и которым она была критична в бизнесе.
Поэтому вам придётся поддерживать 100 % фич. При этом не стоит забывать, что поддержка 10 % самых важных наиболее приоритетна, но от закона Хайрама никуда не деться.
Закон Прайса
В любой группе 50 % работы выполняется квадратным корнем от количества людей.
А это более точная версия распределения Парето для коллектива. Например, в домасковском твиттере было восемь тысяч сотрудников. Соответственно, половину работы делали 90 человек. Может, поэтому после массового увольнения разработка и не развалилась.
Закон Прайса не означает, что оставшиеся люди неважны. Они важны для стабильности разработки, их тоже нужно поддерживать, но всегда нужно помнить о ключевых сотрудниках, делающих ключевую работу.
Эффект Рингельмана
Тенденция к снижению личной продуктивности отдельных членов группы по мере роста её численности.
Если всё сильно упростить, то он о том, что в толпе проще затеряться. Время от времени всплывают истории о сотрудниках государственных ведомств, двадцать лет не ходивших на работу или просто ничего не делающих, чего никто никогда не замечал. Чем больше коллектив, тем выше вероятность наличия таких сотрудников.
Эффект открыл Макс Рингельман в 1913 году. Он проводил эксперимент: просил людей тянуть канат поодиночке и в группах. Оказалось, что в группе каждый прикладывает меньше усилий, чем когда работает один. Например, один человек тянет на 100 % своей силы, а в группе из четырёх — уже только на 75 %. В IT это проявляется, когда команда разрастается, и люди начинают филонить, перекладывая задачи друг на друга.
Грок.
Ещё большие коллективы сильно труднее координировать, чем маленькие. Сотруднику в таком коллективе сложнее добиться внимания руководителя, это тоже не добавляет продуктивности.
Закон Гудхарта
Когда мера становится целью, она перестаёт быть хорошей мерой.
Это про KPI. Если простыми словами, какие бы схемы KPI вы ни придумывали, сотрудники найдут способ манипулировать данными, чтобы их обойти и получить более высокие премии.
Кроме того, если у сотрудника есть выбор — сделать так, как лучше для компании или сделать херню, но получить в этом месяце премию, он сделает херню.
Почитайте примеры про банк и полицейских.
Закон Гилба
Если нужно представить что-либо в количественной форме, это можно измерить каким-то способом, который даст лучшие результаты, чем в случае, если не проводить измерений вовсе.
Более простыми словами. Процессы не измеряются — процессов нет. Ваша работа как пиэма, организовывать измеряшки того, что делает команда. Этот закон как бы противоречит закону Гудхарта, но тут нет противоречия, измерять можно и нужно, некачественное измерение лучше отсутствия измерения. Просто необязательно результаты измеряшек превращать в KPI.
Закон Мёрфи
Если что-нибудь может пойти не так, оно пойдёт не так.
Самый фундаментальный закон подлости из всех. Например, вы решили сэкономить на качестве, применив закон Старджона, сосредоточившись на тестировании 10 % важных фич. Да, 3,5 пользователя всех остальных фич тут же зарепортят кучу багов и испортят репутацию вашей компании.
Или вы проектируете фичу и решаете не описать редкое граничное условие, которое ни у кого не должно возникнуть. Возникнет и очень скоро.
2
