Большая лягушка или большое болото?

Англоязычная версия статьи находится тут.

Навеяно уходом одного из программистов из фирмы нашего египетского парнера в более крупную компанию. Очень хорошо понимаю желания этого программиста поработать в большом проекте, поскольку в компании партнера разрабатывается около 10 разных продуктов, но с каждым продуктом работает 1, максимум 2 человека. Продукты никак не связаны между собой, то есть командной работы практически нет – что одна фирма с 10 продуктами и 1 человеком на каждом из них, что 10 фирм с одним продуктом и одним человеком, разницы никакой.

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

Масштаб

Маленький проект – работа была в проектах от 1 до 8 человека в ИТ отделах небольших страховых компаний, где для каждого вида страхования писались свои модули, либо ИТ отдел предприятия. Проекты, как правило, были для внутреннего использования, типа ERP, бухгалтерии, склада и т. д.

Большой проект – около 2 000 человек в разных странах.

Разделение обязанностей

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

Большой проект – четкое разделение задач. Одна команда работает с безопасностью, другая с архитектурой, которая отвечает за интеграцию модулей и работу с базой данных, остальные команды работают с конкретными модулями. В каждой из таких команд обязанности и задачи тоже разделены. Вполне может получиться так, что ты отвечаешь за функциональность какой-то конкретной кнопки – и пусть функциональность сложная, но однородная работа от версии к версии может однажды очень сильно надоесть. У нас также были ситуации, когда несмотря на то, что весь проект был вокруг базы данных, но детали работы с базой были глубоко запрятаны, так что некоторым программистам знания баз данных вообще были не нужны. Плюс такого подхода в том, что каждый делает то, что он умеет лучше всего, а минус – нет развития в других областях, плюс ты не можешь докопаться до проблемы на низком уровне, если все спрятано и обернуто в красивую упаковку.

Новые технологии и методики

Маленький проект – относительно легко начать использовать новые вещи. Ясно, что после 10 лет разработки с FoxPro не перепрыгнешь на C# в одночасье, но начать использовать такие вещи как ежедневные автоматические билды или юнит тестинг вполне возможно. Причем решения об использовании каких-то новых методик принимаются очень быстро, поскольку нет длинной цепочки уровней менеджмента между программистами и топ шефами проекта.

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

Мэйлы

Маленький проект – тут все просто. Либо послал мэйл своему коллеге, либо просто подошел к его столу, либо зашел в его офис. Вопрос решен.

Большой проект – здесь я первый раз увидел мэйлы нескольким сотням людей одновременно. Но это в случае когда доводят до персонала какую-либо информацию. Ежедневные рабочие мэйлы могли быть посланы 10-20 человекам одновременно. Другой момент, который я увидел – когда присылают мэйл тебе с каким-то вопросом или просьбой, частенько посылают копию твоему шефу. Наверное, это должно каким-то образом гарантировать, что это будет дополнительной мотивацией для меня, поскольку мой шеф помнит все те несколько сотен мэйлов, что ему приходит в виде копий.

Еще один такой момент – уйдя в отпуск на 4 недели, по возвращению тебя будет гарантированно ждать 500-700 сообщений в рабочем почтовом ящике. В маленьких проектах такого никогда не было. Но подобное наблюдается и в нашем стартапе, но это связано с тем, что общаешься с большим количеством людей и много разных событий в связи с этим происходит.

Управление проектом

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

Большой проект – быть топ менеджером большого проекта, это много политики и много стресса. В нашем случае было ощущение, что топ менеджмент вообще работает 24 часа в сутки 7 дней в неделю. Миллион разных планов, встреч и телеконференций с отделами из разных стран и других временных зон.

Смог бы я управлять проектов в несколько тысяч, или даже несколько сотен человек? Думаю, что нет. Во-первых, я думаю, что управление таким проектом требует определенного опыта, и это совсем не тоже самое, что управление 10-20 человеками. И во-вторых, политическими играми заниматься вместо дела удовольствия мало. Так что, если мне дать такой проект-тысячник, то скорее всего я его угроблю.

Интриги

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

Большой проект – интриг много и на разный вкус. Есть своего рода ”здоровые” интриги, когда разные команды борятся за ресурсы, чтобы сделать свою работу качественней и быстрее. А есть грязные – когда идет борьба за позицию, тренируется жополизательный навык и все остальное.

Глупые задачи

Маленький проект – в основном, все по делу. Заниматься всякой ерундой было некогда и некому.

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

Общение с клиентами

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

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

Коллеги и обмен опытом

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

Большой проект – шансов научиться чему-то новому от коллег намного выше. Я считаю, что мне повезло побывать в большом проекте и поработать с более опытными и толковыми коллегами, чем я сам - шведы, индусы, норвежцы, немцы, американцы. Это был и обмен опытом, а заодно и культурный обмен.

Другой интересный момент – за 4 года только в Гетебургском офисе образовалось 4 пары. Но некоторые коллеги развелись со своими мужьями или женами, которые не работали в проекте.

Карьерный рост

Маленький проект – практически отсутствует. Можно станет менеджером проекта, но Большим Боссом не станешь.

Большой проект – есть шанс стать менеджером какой-либо команды, компонента внутри команды или даже Большим Босом. Смотри пункт Интриги.

Командировки

Маленький проект –очень редко. Работа в ИТ отделе какого-либо предприятия не подразумевает командировки куда-либо за редким исключением.

Большой проект – чем мне еще нравился большой проект, так это большим количеством поездок. Ездили часто и много, и сейчас этого не хватает. Одно время, когда были ежемесячные поездки либо в Штаты, либо в Индию, я даже чемодан не убирал. Может быть мне нравились поездки потому, что тогда я не был женат, и у меня не было маленького ребенка :-).

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

В любом случае, этот опыт поможет потом в своем стартапе.