четверг, 1 марта 2012 г.

Корпоративные стартапы

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


Но в чем же эта пресловутая эффективность стартапов, и как можно достичь ее работая в большой конторе? 
Прежде всего секрет эффективности стартапов кроется в отсутствии бюрократии и глупых корпоративных правил. Зачастую в стартапе директор и начинающий девелопер сидят, если не в одном помещение, то уж точно в одном офисе. Любое решение может быть принято практически сразу, ведь все рядом! Но что делать в большой компании? 


Ответ весьма прост. Забудьте, что вы работает в большой компании, если у вас есть свой проект и команда, вам стоит минимизировать зависимости. В идеале, если вы создаете коробочный продукт, внешние зависимости могут быть сведены только к общению с вашим Product Manager'ом.



  • Вы используете монстро-образную систему контроля версии типа TFS, и вам нужно ждать месяц, чтобы маховик корпоративной системы провернулся, и вам создали репозитории? Не пользуйтесь! Возьмите Git, создание репозитория в нем занимает 1 секунду. А если ваша компания мало мальски разумна, то можно будет достать платный аккаунт на GitHub.
  • Вы завязаны на выделенную команду, которая создает setup'ы для всех продуктов вашей компании? Откажитесь! Пользуйтесь WIX, он прост и бесплатен.
  • У вас есть выделенная команда тестеров, которые требуют, чтобы никто ничего никому не отдавал, пока они не посмотрят это в течении месяца? Пошлите их к черту! Тестер - всего лишь роль. Пусть девелоперы отвечают за продукт, пишут автоматические тесты.
  • Целый отдел аналитиков,  архитекторов и продукт менеджеров пол года рисует UML и пишет бесконечные MRD? Да ваш продукт уже не нужен будет когда они закончат! Делайте короткие итерации, показывайте продукт всем. Максимум, что вам придется, так это немножко изменить сделанное. Уверяю, это будет быстрее, чем ждать идеальные документы. Все равно их поменяют уже после начала работы.
  • От вас требуют бесконечной проектной документации с разбивкой по человеко-минутам? Спасите деревья! Нарисуйте backlog на доске с вашим планом на текущую итерацию или используйте online планировщик типа PivotalTracker
  • Вы зависите от корпортивного багтрекера, который, мягко говоря, даже в момент своего выхода был страшен, а это было 10 лет назад и работе с ним нужно специально учится? Отправьте его на пенсию! Возьмите тот же Youtrack ,он бесплатен для 10 человек, вам хватит. 



Если вы это проделали, то вы уже практически стартап, и ваша эффективность возросла в несколько раз.

9 комментариев:

Eduard Kibort комментирует...

TFS можно и свой поднять (если разговор идет о нескольких командах) и вы работаете со студией. В остальном по пунктам согласен.

Eduard Kibort комментирует...

Сомневаюсь что поднятие TFS сравнимо по сложности с установкой Git. :)

Eduard Kibort комментирует...

OMG! Как показывает практика - далеко не все большие конторы вообще разрешают использовать что-либо, кроме утвержденных "политиками" инструментов, тем более для контроля версий. А если еще и метрики используются, то даже поставленный локально полу-легальный гит придется ежедневно интегрировать с TFS или, еще похуже, Perforce.

Eduard Kibort комментирует...

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

Eduard Kibort комментирует...

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

Eduard Kibort комментирует...

На счет документаторов - соглашусь, хотя как показывает практика всё равно ее никто не читает. :) А вот саппорт до некоторых пределов можно передать девелоперам. Для них это будет полезно. Само собой, что зачастую, от отдельного саппорта отказаться нельзя, из за разницы во времени и языковом барьере. Но ситуация когда девелоперы совсем не в курсе кто и как пользуется продуктом чревата.

Eduard Kibort комментирует...

Как показывает практика - вы ОШИБАЕТЕСЬ!!! документация очень важна... просто вы не видите этого... ты не представляешь насколько это просто сказать - "ну у нас же в документации написано!"
не говоря уже о том, что невозможно знать все... и если задается вопрос ответ на который ты не знаешь... то первое место где смотреть - документация!

насчет практики сапорта соглашусь, но в таком случае можно сильно погрязнуть в саппорте и не останется времени на разработку.

Eduard Kibort комментирует...

А мне понравился опыт, когда для таких целей, пользовались онлаин документацией и постепенно расширяли в тех местах где появлялись вопросы.

Eduard Kibort комментирует...

Да онлайн документация это тема!!! но ведь ее никто не пишет :(