Где находится точка невозврата вашего стартапа? 7 мифов о предпринимательстве и программировании

Тим Феррисс представляет интервью с Робом Ми, основателем известной компании по разработке софта, Pivotal Labs:

За последние пару лет, когда я говорил об инвесторах стартапов класса А, мне все чаще приходило на ум название Pivotal Labs.

Знаете, Pivotal Labs без особой шумихи помогает десяткам быстро развивающихся технических компаний по всему миру, включая такие как Групон или Твиттер. Если вашему стартапу нужен хороший код и не просто нужен, а очень быстро (порой — молниеносно быстро), то топовые бизнесмены дадут вам такой совет: «Позвоните в Pivotal Labs».

Я же впервые встретился с основателем Pivotal Labs Робом Ми, когда с ним начал сотрудничать один стартап TaskRabbit, которому я помогал.

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

Наш парень.

Затем я задал ему несколько вопросов:

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

Какие мифы о создании технической продукции (особенно в области программирования) он хотел бы разоблачить?

Эта статья содержит его подробные ответы.

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

Давайте послушаем Роба Ми:

Разработка программного обеспечения — быстро развивающая отрасль, у которой было весьма бурное начало.

На протяжении многих лет было принято считать, что программирование схоже с другими видами инженерии: тщательно спроектируйте, точно выверите, а потом просто стройте — все согласно чертежам. Прямо как строительство моста. Но беда такого подхода кроется в том, что программирование работает не так. Софт обладает бесконечно податливой структурой. Вы можете существенно изменять свою программу, когда посчитаете нужным, многие так и делают.

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

Программирование не похоже на строительство мостов.

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

По правде, они должны быть настроены на перемены. И ничего это не касается сильнее, чем современное сообщество интернет стартаперов. Так называемые гибкие методы вошли в тренд и движение «экономные стартапы» требует чрезвычайно быстрых изменений, часто автоматизированных, основанных на экспериментах с живой системой.

Но у нас с этим все в порядке, да? Не так быстро. Несмотря на принятие более гибких методов, в этой сфере еще полно «премудростей», от которых давно пора избавиться.

1 . Миф: Вы должны нанимать «ниндзя»

Миф о герое-хакере — одна из самых распространенных ошибок для стартапов Силиконовой Долины: сама идея, что один программист, плотно подсевший на кофеин и пиццу, обязательно в наушниках, работает ночи на пролет, чтобы в одиночку создать комплексную систему. Коней попридержите. Программирование, оказывается, командный вид спорта. Все стартапы растут, если их настигает более-менее значимый успех. И работа с одним программистом очень отличается с работой с командой из 10.

А что еще хуже — поощрение героя-одиночки приводит к дисфункции рабочей команды программистов. Несомненно, работающие по стандартной схеме 9- 5 разработчики проигрывают тем маньякам, которые не спят всю ночь (одну ночь, как правило), после которой и собирают щедрые похвалы. Но чем взращивать культ героя, лучше заняться воспитанием истинного духа единства.

2. Миф. Программисты должны работать в тишине и без перерывов

В этом есть резон… если люди работают на себя. Любое вмешательство сбивает концентрацию и тратится лишнее время на то, чтобы опять сконцентрироваться. Некоторые известные компании-разработчики даже утверждают, что у них каждому программисту отводится свой офис. Так они никогда не будут отвлекаться. Исключая тот факт, что сегодня перерывы — это не коллега, который похлопал вас по плечу, это скорее постоянно приходящие сообщения, мобильники, просмотр Facebook и Twitter, чтение емейлов, и конечно музыка из наушников, которая, как божатся программисты, помогает им концентрироваться.

По правде большинство программистов, которые работают на себя, тратят на само программирование не так уж много времени: безумное количество отвлекающих факторов, большая часть дня уходит на борьбу с ним и концентрацию. Однако есть и решение проблемы: парное программирование. Два программиста, один компьютер. Никаких емейлов, твитов, телефонных звонков (по крайней мере незапланированных, можете брать заранее обозначенные перерывы для этих мелочей).

Если вы прибегните к такой системе, то получите целый день чистой работы над программой. При совместной работе оставаться в нужном ключе очень легко. Это совсем иной метод работы, и я считаю, что он куда более эффективен, чем любая работа в одиночку. В действительности при том количестве отвлекающих девайсов на рабочем месте подобный метод — единственный, когда команды программистов могут работать максимально эффективно.

3. Миф: Стартапы нужно клепать быстро, так что будем работать на износ

Работа на износ не поможет вам стать быстрее. На самом деле это только замедлит процесс. Конечно, неделю можно повыкладываться. Но большинство стартапов планируется на срок немного больший, чем неделя. Разработчикам будет нужно программировать месяцами, если не годами, чтобы создать лучший продукт. Многие стартапы работают так, будто большой куш уже не за горами, и если он еще чуть поднажмут, то сорвут его.

Очень скоро разработчики выгорают и далее проведенное ими время за монитором не отличается особой производительностью. Интенсивная работа небольшими периодами куда эффективнее. Pivotal помогла сотням стартакпов отладить системы, и сделала это на базе 40-часовой рабочей недели.

4. Миф: Сжатые сроки требуют идти на компромиссы

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

Напротив, важно умение оставаться спокойным под давлением, дать вашему опыту привести вас к успеху. Сколько раз мы слышали истории о невероятных результатах. которых добились под невозможным давлением — будь то в военной сфере, профессиональном спорте, или в рассказе о пилоте, посадившем самолет на реку, и большинство героев в этих случаях говорило: «Мы тренировались на такой случаи».

5. Миф: Разработчикам должны принадлежать права на код

«Собственность» — неплохо звучит, очень по-американски, прямо как яблочный пирог. Личная ответственность, да? Но «собственность» для команды разработчиков означает, что пишет только один программист, и он же понимает каждый модуль кода. Это приводит не незащищенности от разработчика. Кроме того, для владельца бизнеса реальным становится риск, что потеря одного человека замедлит работу всей команды или даже парализует дело, если этот человек нес ответственность за чрезвычайно важную часть системы.

Процесс будет куда здоровее, если любой разработчик может работать над любой частью кода в системе. Этому способствует парное программирование, потому что специалисты в связке обмениваются знаниями. Так называемый «автобусный счетчик» (то есть сколько человек из вашей команды должно попасть под автобус, прежде чем проект пойдет ко дну). Тут имеется ввиду не именно автобус, это могут быть и ваши конкуренты, переманившие лучших разработчиков. Чем больше людей понимают работу всей системы, тем сильнее и устойчивее ваша организация.

6. Миф: Вам нужен изворотливый процесс приема на работу

Кто будет нанимать актера без прослушивания? Вы не долго протянете в качестве директора, если будете так поступать. Но именно так поступает большинство современных компаний, нанимающих разработчиков программного обеспечения. Весь процесс обычно состоит из беседы с претендентом об его опыте. И на этом все. Представьте, начни вы спрашивать актера, понравилось ли ему играть Гамлета. Вы хорошо его сыграли? Ну тогда отлично. Вы приняты!

Множество известных компаний по разработке софта предлагают претендентам решить головоломку. Некоторые компании даже дают кандидатам прорешать тест на IQ. Лучшие из них предлагают решить на доске смоделированную проблему в области программирования. В этом плане положение дел довольно печально. Я сейчас скажу казалось бы очевидную вещь: единственный способ нанять хороших программистов — самим попрограммировать с ними. Я провожу с программистами часовое интенсивное интервью в формате парного программирования, — и это только для начала.

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

7. Миф: Важна специализация

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

Каждый человек в любой команде должен понимать все уровни процесса. Почему? Потому что узкое специализирование делает команду слабой. Помните про систему «автобусного счетчика»? Каждый специалист делает систему зависимой, если он уйдет, а вы не сможете заменить его, проект ждет провал. И не только в этом дело, специализацию лишают команду целостности. Специалисты делают разрозненные части системы, которые взаимодействуют через интерфейсы. Все кончается неформальной перепиской друг с дружкой, как же с этим работать. Что влечет массу лишних расходов, перекладыванию вины друг на друга и оборонительной позиции. В Pivotal каждый разработчик работает на любом уровне системы, от HTML и JavaScript до Ruby и баз данных.

Аргумент, что на своем одном уровне специалист был бы эффективнее и продуктивнее, не выдерживает критики. Состояние современных технологии не такое уж запутанное. Программистам лучше знать все уровни работы и то, как они связаны. Кстати, еще один важный вывод из этого: не стоит нанимать человека для работы над определенной технологией.

Не хватает программистов по Ruby? Ничего, наймите программистов Java и научите их работать с Ruby (они прекрасно учатся по методу парного программирования). Некоторые считают себя «серверными» программистами? Не беда, дайте им JavaScript, они быстро втянутся.