вторник, 11 июня 2013 г.

[prog.process] Несколько вещей, которые не могу для себя прояснить

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


Первая вещь -- это эффективность специализации при разработке ПО. Я начинал работу программиста в тяжелые для этой отрасли на просторах СНГ времена (середина 90-х), в развалинах одной из крупнейших в СССР контор по разработке ПО. Поэтому тогда программисты были многостаночниками во всех смыслах. Начиная от спектра технологий и заканчивая выполняемыми обязанностями. Программист был и проектировщиком ПО (архитектором по нынешним меркам), кодировщиком (т.е. программистом в современном представлении), тестировщиком и техническим писателем. А в некоторых случаях (времена были голодные и каждый коллектив выживал как мог) опытный программист выступал и в качестве bisiness analyst-а + solution architect-а + project manager-а. Все в одном флаконе. Ну и как бы ничего, справлялись. У кого-то были проблемы с написанием документации, у кого-то в общении с клиентом. Но такие вещи решались в рабочем порядке, зачастую по принципу "глаза боятся, а руки делают".

Сейчас же я вижу практически повсеместное использование узких специализаций. Есть разработчики, архитекторы, тим-лиды, тех-лиды, тестировщики и тест-аналитики, технические писатели и т.д. Ситуация, по сравнению с серединой 90-х, изменилась кардинально.

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

Но вот что хотелось бы для себя уточнить, так это проводились ли какие-нибудь исследования эффективности такой специализации в различных условиях. Мне представляется очевидным, что далеко не всегда наличие узких специалистов будет обходится работодателю дешевле, чем "многостаночников". И, наверное, это зависит от ряда факторов, например, размера задачи, ее характера (типовой проект или исследовательский), типа релизной политики (поставка к сроку, по реализации функционала) и т.д. и т.п.

Или же эффективность узкой специализации воспринимается как "общеизвестный" факт и сомнениям не подвергается?


Вторая вещь -- это тенденции к передаче разработки софта в аутсорс. Мне интересно, насколько эти тенденции сильны и как они изменяются с течением времени.

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

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

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

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


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

Если я правильно вижу мир, то у владельцев аутсорсинговой компании и, скажем, продуктовой компании, разные способы достижения одной, общей для всех цели: построение устойчивого и прибыльного бизнеса. Способ аутсорсера -- выстроить процесс успешного массового выполнения заказов. Способ продуктовой компании -- создание, продвижение и обслуживание продукта(ов).

Соответственно, моральная мотивация сотрудников продуктовой компании выглядит достаточно очевидной: "Мы выпускаем лучший в мире продукт!" или "Наш продукт самый востребованный!" или "Наш конкурент выпустил действительно удачный продукт X, но ведь мы можем сделать свой Y намного лучше". Понятное дело, что чем крупнее становится продуктовая компания (например, масштабов Philips или Sony), тем хуже работает такого рода мотивация. Но деление на "свой" и "чужой" все равно очень четкое и на том, что "свое" должно быть лучше, чем "чужое", можно и нужно играть.

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

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

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

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

Отправить комментарий