Boatman's Home:  О сайте   Новости   Карта  
Статьи и заметки о менеджменте и системном анализе в ИТ + мысли о трудовых отношениях, рынках труда, услуг и программных продуктов
Это страница на старом движке. Новые статьи здесь
2007-08-12 01:15    Boatman   Обсудить в Google Groups   Перейти на страницу обсуждений

Данная статья создана для размещения на сайте boatmanshome.ru. Автор и обладатель исключительного права на эту статью - Нужненко Сергей Александрович.
Для данной статьи автор разрешает размещение ссылок и цитирование, а так же воспроизведение в личных и учебных целях.
Без согласования с автором запрещается для данной статьи или любой ее части воспроизведение в коммерческих целях, а так же любые распространение, публичный показ, импорт с целью распространения, прокат, переработка, сообщение для всеобщего сведения.
Для согласования видов использования статьи можно связаться с автором по e-mail: haron@ru.ru с пометкой в теме "Boatmanshome-text-use".

Война миров?

   Две твердыни
   Кто я?
   Что дальше?

Две твердыни  ^

Я начал работать программистом, когда был еще студентом. Тогда же программистами начали работать многие мои знакомые. Спустя совсем немного времени, на основании сравнения своего и их опыта, начало формироваться смутное ощущение, что ИТ индустрия поделена на два непримиримых лагеря, разделенных высокой непробиваемой стеной непонимания. К несчастью, формирование этого ощущения началось с учащающихся замечаний некоторых знакомых, что в "нормальных компаниях" так не бывает, в ответ на мои рассказы о своей работе. Далее следовали рассказы, как надо, и это было настолько правильно и непогрешимо, что становилось даже неуютно. Конечно - это было немножко обидно, зато стимулировало поиски истины. Время шло, я закончил учебу и стал все реже видеться со своими старыми друзьями и знакомыми. Ощущение притупилось, поиски истины остались. Иногда еще, обсуждая работу, я снова сталкивался с позицией и психологией отличной от своей, но тогда уже было и больше уверенности в своей правоте по отношению к своим делам, а значит, чужая позиция уже не так задевала.
И вот не так давно на одном из семинаров, я столкнулся при обсуждении с настолько агрессивным взглядом на вещи "с той стороны", что задумался снова и решил вынести вопрос на обсуждение.
Сначала эти лагеря условно назывались у меня "Западный" и "Восточный".
Западный лагерь характеризовался такими словами, как "нормальная компания", "сертифицированный специалист", "дисциплина" и т.д. С виду это были большие компании: аутсорсеры для западных заказчиков, или чисто западные торговые марки, или чисто российские монстры - кузницы кадров. Внутри них царили узкая специализация, борьба за дисциплину, корпоративная культура и прочие радости, которые в запальчивости одно время я называл "казарменными". Отлаженная технология в таких компаниях (с виду) всегда отвечала на вопрос: "что делать?". Время показало, что начинающему там лучше, так как с большой вероятностью там есть старшие товарищи, у которых можно учиться и посмотреть на какой-никакой ПРОЦЕСС разработки программного обеспечения. Дорога специалиста, которому комфортно в таких условиях, в узкую специализацию, углубление навыков и дальнейший профессиональный рост в выбранной области. Работа чаще всего размерена, переработки случаются реже, одновременно человек тянет не больше двух проектов.
Восточный лагерь характеризовался малым размером компании (или отдела), отсутствием четкой формализованной технологии, как, впрочем, и дисциплины вообще. Человек в такой компании закрывает целое направление и отвечает сразу за все аспекты, являясь по сути "человеком оркестром". Новичку в такой компании тяжеловато, так как посоветоваться практически не с кем. После пары лет работы доводится поработать с десятком технологий, но ни с одной долго и детально, что не украшает резюме. Время тратится на решение организационных проблем, и множество других мелочей, не относящихся к делу. Количество проектов никто не считает, но обычно их может быть и 5 и 10 и гораздо больше. Проработав достаточно долго в таком режиме, обнаруживаешь, что дорога тебе или в младшие специалисты в Западном лагере, или в такие же затычки в каждой дырке в другой мелкой конторе, или в начинающие менеджеры, предприниматели, аналитики или консультанты по внедрению. То есть продуктивное построение карьеры сопровождается сменой обоймы.
Некоторое время спустя наблюдение за рынком труда в ИТ дополнились наблюдениями за рынком ИТ услуг. Оказалось, что заказчики точно так же делятся на два лагеря. Заказчики Западного лагеря знают, чего хотят с точностью до кнопки и способны сформулировать и подписать спецификацию требований к системе. Суммы договоров впечатляют и измеряются многими десятками и сотнями тысяч долларов. Заказчики Восточного лагеря никогда не знают, чего хотят. Специфика отечественного рынка и особенности национального менеджмента не позволяет им заказывать консалтинговые услуги. Поэтому они покупают услуги по разработке и внедрению софта, в которые обязательно прячется консалтинговый проект. Другой вариант - продвижение идет методом проб и ошибок. Суммы договоров могут быть маленькими и очень маленькими и начинаются от единиц тысяч долларов.

Кто я?  ^

Последний раз в споре, который спровоцировал написание этого материала, выяснилось корневое отличие этих двух систем. В случае Западного лагеря цели ставятся достаточно тщательно и достаточно далеко от производства софта. Как следствие, есть четкое представление о результате и предсказуемость процесса разработки. В Восточном лагере цели размыты, образ результата не до конца предсказуем, что накладывает отпечаток на весь процесс разработки и обуславливает его непредсказуемость. Это корневое отличие систем и позволяет ответить на вопрос: "как случилось, что о целях проекта должен думать разработчик или аналитик?".
И, конечно же, размышления о лагерях и целях позволило мне ответить вопрос, мучавший одного из героев моего любимого фильма: "Кто я?", а так же дать правильные названия лагерям.
Как выяснилось: вся моя программистская молодость прошла в венчурном и инновационном сегменте ИТ индустрии. Есть разница между расширением функций биллинговой системы, или заменой одной биллинговой системы на другую и внедрение с нуля автоматизированной системы там, где ее никогда не было. Разница в степени риска, неопределенности результата, а также в объеме технико-экономического обоснования разработки и внедрения. Разница также в масштабе перемен, как в технической области, так и в организационной.
Инновационная деятельность существует не только в рамках специальных венчурных банков и фондов. В большинстве компаний внедрение системы автоматизации является инновационным проектом, так как никогда ранее ни подобной системы, ни подобной организации работы в компании не было. Именно молодость ИТ в России и инновационный характер ИТ проектов и объясняет повышенную степень их риска.
Естественно, особенности национального ИТ часто не позволяют уделить внимание таким мелочам, как технико-экономическое обоснование или серьезная формализация целей инновационного проекта, что часто делает проекты неуправляемыми и обрекает их на провал. Однако попытка обоснования часто душит идею на корню, показывая все предстоящие проблемы и неопределенность. Поэтому нельзя считать, что отсутствие обоснования и четкого целеполагания являются однозначным злом. Достаточно часто требуется быстро попробовать, и, в случае успеха, зафиксировать результат. Наверное, старт и проведение инновационного проекта в корне отличаются от консервативного проекта с поверенными годами целями и средствами их измерения. В этом, я думаю, и заключается основное отличие лагерей, обуславливающее и различные методы ведения дел и различную психологию функционеров.

Что дальше?  ^

Четкое определение, чем на самом деле являются два непримиримых лагеря, позволяет понять суть разногласий и дать рекомендации для некоторых случаев. В первую очередь для нанимающихся на работу:
- новичкам: в венчурном проекте риски слишком высоки, обязанности могут быть размыты, что не лучшим образом скажется на резюме;
- аналитикам и менеджерам: в венчурном предприятии могут быть проблемы с обоснованием и формализацией целей, об этом можно задать соответствующие вопросы на собеседовании;
- продавцам услуг по внедрению: неготовность клиента к внедрению сразу перемещает проект в зону повышенного риска, можно использовать красивое слово "инновация" для того, чтобы убедить руководство клиента включить в проект консалтинговую фазу.
Во-вторых, при описании и обсуждении методов анализа и управления проектами можно предполагать, что методы различны в зависимости от характера проекта, и точно определять предполагаемую область действия или условия апробации.
И теперь, конечно, у меня есть "ответ Чемберлену". ИТ, особенно отечественные, не могут быть целиком консервативными и предсказуемыми. Развитие многих компаний сегодня таково, что большая часть рынка ИТ услуг является инновационной, что обуславливает повышенный риск. Предсказуемые ИТ проекты остаются уделом крупных отечественных компаний и аутсорсеров.
Остается вопрос, каково место и роль спецификации требований в типичном инновационном ИТ проекте? Как убедить заказчика в необходимости консалтинговой фазы и стоит ли это делать вообще?
Я думаю, чуть позже мы еще поговорим об этом...