К примеру, давайте представим одну маленькую компанию, которая выпустила продукт с небольшим набором функций, и компанию, у которой есть продукт с обширным функционалом. Далее возникает новая технология, например, AJAX, или новая идея, как, например, теги. Кто из них в состоянии быстрее приспособить эти технологии к своему продукту? Команда с огромным проектом, кучей функций и планом на год, или команда с маленьким продуктом и более органичным подходом, который гласит «давайте будем делать то, что нам нужно сделать прямо сейчас»?
Очевидно, что небольшая компания находится в лучшем положении и лучше приспосабливается к реальным требованиям рынка. Более крупная компания будет, вероятно, будет обсуждать изменения или проталкивать их через бюрократическую машину еще долго после того, как маленькая компания уже все сделает. Небольшая компания на два шага впереди, в то время как большая компания все еще думает куда идти.
Ловкие, проворные и легковесные компании могут быстро менять свою бизнес-модель, продукт, его функции и маркетинг. Они могут делать ошибки и быстро их исправлять. Они могут менять приоритеты, и что самое важное — у них есть право передумать.
Снизьте стоимость перемен
Будьте гибкими, снижая препятствия для перемен
Перемены — ваш лучший друг. Чем выше их цена, тем меньше их вероятность. И если ваши конкуренты могут меняться быстрее вас, вы в крайне невыгодном положении. Если цена перемен становится слишком высока — вам конец.
Вот где бедность действительно поможет вам. Копеечная стоимость перемен — это то, что есть у маленьких команд по умолчанию, у больших команд этого не будет никогда. Вот тут большие ребята действительно завидуют маленьким ребятам. В большой организации на какое-то изменения потребуется неделя, а в малой — это займет всего один день. Это преимущество бесценно. Дешевые и быстрые перемены — секретное оружие малого бизнеса.
И помните: все деньги, весь маркетинг, все люди в мире не могут купить проворство, которое вы получаете уже от того, что вы невелики.
Непредсказуемость
Непредсказуемость одно из основополагающих принципов проворства, и очень близко к чистому волшебству. Неожиданно появляющиеся свойства не проектируются или строятся, они просто случаются, как динамичный результат остальной части системы.
«Непредсказуемость» происходит с середины 17-го столетия из латинского словосочетания «непредвиденный случай». Вы не можете спланировать это, но вы можете культивировать окружающую среду, в которой позволите этому случиться и извлечь из этого выгоду.
Классический пример непредсказуемости лежит в поведении стаи птиц. Компьютерное моделирование может использовать только лишь три простых правила (например, параллельные линии не пересекают друг друга), и вдруг вы получаете очень сложную схему, как стая двигается и ведет свой путь грациозно через небо, огибая препятствия. Ни одно из этих правил не предполагает такого поведения, как, например, изменение строя во время преодоления препятствия, это возникает из динамики системы.
Простые правила, как с моделированием птиц, приводят к сложному поведению. Сложные правила, как, например, налоговое законодательство большинства стран, провоцируют глупое поведение.
Методы разработок стандартного программного обеспечения обладают досадным побочным эффектом: они исключают любую возможность непредсказуемого поведения. Большинство попыток оптимизации этого процесса и привязке к конкретным правилам сужают разнообразие взаимодействий и отношений, которые являются источником непредсказуемых поступков. Стая птиц — это пример разумной системы, в которой взаимодействия и взаимоотношения создают любопытное поведение.
Чем больше жестких установок мы применяем, тем меньше места для творческих и необычных решений. Разрабатываете требования прежде чем как следует в них разберетесь, слишком рано оптимизируете код или изобретаете сложную навигацию и схемы действий до того, как пользователи увидят систему — результат один: усложненная, неразумная система вместо простой и элегантной, взявшей на вооружение неожиданность.
Будьте небольшими. Будьте проще. Позвольте вмешаться динамике и непредсказуемости.
— Эндрю Хант, The Pragmatic Programmers
Три Мушкетера
Используйте команду из трех человек для версии 1.0
Чтобы выпустить первую версию вашего продукта, можно начать только с тремя людьми. Это магическая число, которое обеспечит вам достаточный человеческий ресурс и в то же время позволит оставаться быстрым и проворным. Начните с разработчиком, дизайнером, и человеком, — который разбирается в том и другом.
Конечно, это вызов — создать продукт, имея лишь нескольких человек. Но если у вас правильная команда, это того стоит. Талантливым людям не нужны бесконечные ресурсы. У них есть энтузиазм. Их творческий потенциал можно использовать для решения проблем. Недостаток человеческого ресурса означает, что вам придется идти на компромиссы сразу — и это правильно. Это заставит вас раньше задуматься над приоритетами. И вы сможете сразу же наладить связь в команде, не беспокоясь о том, что кто-то останется за бортом.
Если вы не можете создать версию 1.0 с тремя людьми, то или вам нужны другие люди, или необходимо понизить начальные требования. Запомните, простая и легкая первая версия — это нормально. Вы быстро увидите, если ваша идея хороша — у вас будет чистая и простая основа для дальнейшей работы.
Закон Меткалфа и проектные команды
Удерживайте команду насколько возможно маленькой. Закон Меткалфа, который гласит «полезность сети приблизительно равна квадрату численности пользователей этой сети», применительно к участникам команды обретает иной смысл: эффективность команды обратно пропорциональна квадрату количества ее участников. Я начинаю думать, что три человека — оптимально для версии 1.0… Начните с сокращения списка людей, которых вы хотите пригласить в команду, а затем сократите его снова.
— Марк Хедлунд, предприниматель-консультант в O'Reilly Media
Пути взаимоотношений
Пути взаимоотношений в маленьких командах проще, чем в больших. Если вы — единственный человек в проекте, взаимодействие происходит только между вами и клиентом. Если число людей в проекте увеличивается, возрастает и количество путей взаимоотношений. Их количество не возрастает последовательно, как увеличение численности людей, поток увеличивается многократно, пропорционально квадрату числа людей.
— Стив МакКоннелл, ведущий проектировщик ПО в Construx Software Builders Inc. (из статьи Less is More: Jumpstarting Productivity with Small Teams)
