Про «инофирмы»

Как начать работу, как построить взаимоотношения так, чтобы они были выгодны обеим сторонам? Скромный файл «О гайке М3 и о ТЗ на разработку» имеет, наверное, самый высокий рейтинг из всех написанных автором статей. А это значит, что материалы такого рода очень интересны читателям. Именно поэтому, получив письмо от Евгения Аржанова из города Брянска, автор написал развернутый ответ на один из его вопросов. Ситуация такова: «иностранная фирма» предложила Евгению очень срочно сделать некоторую работу. И при этом обещала прилично заплатить. Вроде бы все хорошо. Да вот только сроки выполнения работ показались Евгению нереальными. И он захотел узнать, можно ли сначала как-то «ввязаться в дело» и уже в ходе выполнения работы попытаться изменить сроки выполнения задания?

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

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

Далее повествование ведется от первого лица. Все остальные материалы автора, на которые он будет ссылаться в этой статье, доступны читателям на сайте [1] в разделах «статьи», «письма», «сказки» и т. д.

Фрагмент письма

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

Интересуюсь потому, что меня нашла похожая фирма и дала противоречивое ТЗ с жесткими сроками, а поскольку приличную ЗП начали платить сразу, пришлось согласиться, надеясь подкорректировать ТЗ в процессе (издержки первого опыта такого фри-лансерства)…»

Итак, про «инофирмы»

Наверное, мой небольшой опыт работы в фирме доктора Алекса (Алекс имел степень доктора IEEE) может быть полезен читателям. Я здесь приведу несколько моих наблюдений и суждений. Возможно, это не все аспекты данной проблемы, а только те, с которыми я столкнулся. Но тем не менее, это мои суждения, и в их основе лежит мой опыт. Я не берусь говорить нравоучительным тоном о том, «что такое хорошо и что такое плохо». Здесь я только хочу сравнить два стиля разработки — «наш» и «их»… «Наш» — это то, как мы привыкли делать разработки с «давних времен». Здесь под термином «мы» я имею в виду как «бывшие» государственные предприятия, так и новые фирмы, но руководимые «нашими» менеджерами, то есть теми, кто учился работать по «нашим» правилам. И стиль руководства, и планирование в таких фирмах зачастую можно представить следующей фразой: «Жарьте, ребята, масло подвезут». А вот «их» стиль — это в чистом виде иностранный менеджмент.

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

Конечно, я могу в чем-то ошибаться, так как я не владелец фирмы и не знаком с тонкостями финансирования и разделения госзаказа, но для инженера-разработчика это и не самое главное.

Мы одинаковые и мы разные

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

Начнем это сравнение с самого главного. С того, кто и каким образом организует производство.

«Наше» производство раньше обычно начиналось с утверждения «темы» в ЦК КПСС, в министерствах и тому подобных организациях. Детали тут не важны. Важно то, что под «громадье» планов выделялось финансирование и квоты на фондируемые комплектующие. Сразу же определялся и завод — изготовитель продукции. Зачастую заводское КБ подключалось к разработке проекта уже на этапе изготовления опытных образцов. То есть финансирование выделялось до начала работ и по окончании темы закрывалось. Думаю, что таким же образом идет процесс при выполнении госзаказа. Сначала получают деньги, потом идет разработка.

Большинство же современных фирм, особенно небольших, «разработческих», насколько мне известно, не имеют возможности для привлечения сторонних денег. Или же сначала инициативная группа делает разработку «на кухне» или «в гараже», а потом организуется фирма. Безусловно, все знают историю Стива и Джобса. Персональный компьютер был изобретен ими именно в гараже. И у нас в стране тоже достаточно фирм, история которых начиналась словами: «Собрались единомышленники и в инициативном порядке разработали». Иногда группы разработчиков уходили из одной компании и основывали другую. Например, группа разработчиков-единомышленников ушла из Intel и организовала фирму Zilog. В этом и мы, и они похожи. А вот дальше начинаются различия.

Как ведется разработка у «нас»? Обычно все делается либо в инициативном порядке, либо разработка ведется на собственные средства. Что в этом плохого? Мало денег! А деньги, безусловно, нужны на приборы, программные инструменты, аренду помещений, на зарплату наконец. Конечно, «мы» научились выкручиваться «по-нашему». Софт — это либо бесплатная версия, либо «вылеченная от жадности», как ее называют в конференциях. Приборы старенькие или взятые в долг у знакомых. Ну и так далее. В любом случае отечественный предприниматель понимает, что брать кредиты — это значит получить петлю на шею. Если кто-то из читателей готов привести примеры успешной работы малой фирмы, работающей с привлеченным капиталом, то автор (и журнал, конечно) будет только рад опубликовать такой пример. А с другой стороны, в таком стиле работы есть и много хорошего. Сделал «сегодняшнее задание» именно сегодня — хорошо. Не сделал, так ничего страшного в этом нет. Завтра нагоним. Получили какое-либо срочное указание, требующее отложить разработку на день или на неделю, например, нужно съездить к клиенту и «разобраться с его вопросами», так тоже ничего страшного. «Это наш клиент, мы его не можем обидеть…» — вот ключевая фраза начальника. Ну что же, отложим эту работу сегодня и нагоним ее завтра или не нагоним ее вовсе. И если не нагоним, то получим опоздание на один-два дня. Фирме, как таковой, это ничем сильно не грозит. Сегодня один или несколько разработчиков из группы, работающей над проектом, может быть отвлечен на какую-то другую тему, а в будущем, когда тема начнет «гореть», можно будет добавить людей из других групп или, в крайнем случае, нанять дополнительных сотрудников.

Теперь давайте посмотрим, как это делается у «них». Для «инофирмы» правила игры несколько другие. Они не имеют права применять «вылеченный от жадности» софт, им надо полностью отчитаться о разработке. Если изделие сертифицируется, то «извольте показать», как и какими программными и аппаратными средствами оно было разработано. Сертификаты, лицензии, права на использование, патенты и т. д. А это значит, что с самого начала разработки требуются довольно большие затраты. Следовательно, фирма вынуждена работать на заемных средствах. Особенно если это небольшая фирма. А заемные деньги — это либо банковский кредит, либо деньги акционеров, либо что-то еще. Но в любом случае сразу же, как только в дело привлекаются заемные деньги, оговаривается срок возврата этих самых заемных средств. А правильность расходования заемных денег проверяется аудитом. Вот почему, как было сказано выше, приходится «играть в открытую». И вот в этом и есть основа всего! Да, мы знаем, что «долг платежом красен», но на бытовом уровне — работая по «нашим» правилам, мы этого не ощущаем. А вот для инофирмы это совсем не далекая абстракция. Для них это и есть самая суровая реальность.

Проект начинается с разработки графика его проведения. Под этот график вычисляется трудоемкость выполнения отдельных этапов, и под каждый этап определяется требуемое число сотрудников. Некоторые дополнительные сведения по трудоемкости проектирования и по организации работ можно найти в моей статье «О Квадриге» [1]. И как только определено «сколько и где», сразу же начинается поиск денег. Ищутся инвесторы под еще несделанный проект. Под идею, под бизнес-план. Найдены деньги — можно начинать разработку. А не найдены, так и разрабатывать будет невозможно!

Если планирование проведения разработки произведено правильно, то она выполняется успешно. Но представьте ситуацию, когда что-то не учли и нужно «еще немного попрограммировать». Хотите взять дополнительных сотрудников? Увы, это не всегда возможно. Ведь вы же не отдадите свою зарплату кому-то, только потому, что вы не в силах сделать работу даже при 12-часовом рабочем дне, верно? Также невозможно сильно потратиться на какие-либо приборы или инструменты, только потому, что «это не учли в самом начале». Далее, невозможно даже отвлечь сотрудника по «воле начальника», если время на такое отвлечение не было заложено в график работ.

Какие из этого следуют выводы:

1. Вы говорили, что хотите потом что-то поменять, «надеясь подкорректировать ТЗ»… Теперь, я думаю, вам должно быть понятно, что скорее всего никто не будет корректировать ТЗ, если это как-то может изменить планирование работ. Хотите сделать больше, но за те же деньги и в те же сроки — пожалуйста. Но если вы предложите увеличить сроки или заплатить вам больше, то ответ скорее всего будет «нет»! Правда, при этом необходимо учесть, что вы можете предложить как-то улучшить разрабатываемое изделие. И тогда, возможно, вам удастся убедить руководителя проекта пожертвовать частью резерва времени или денег.
2. Начиная работу с инофирмой, нужно сразу оговорить объем работ и версии примененных программных инструментов. А также условия приема/сдачи работ. Если фирма хочет получить от вас какие-либо файлы, например, файлы конструирования печатной платы для передачи их изготовителю, то необходимо уточнить, будет ли фирма проверять лицензию у ваших программных инструментов. Или компания на период работ по контракту может предоставить вам лицензию на пользование определенным программным инструментом. Я не думаю, что инофирма, получив от вас файлы, будет уже от своего имени передавать соисполнителям какие-либо файлы, сделанные на нелицензионном софте. Но даже если у вас стоит лицензионный софт, то все равно могут быть «подводные камни». Как я уже писал, при планировании ведется режим жестокой экономии. Ведь за заемные деньги надо платить, и платить много. Поэтому они экономят на всем. Для тех, кто пользуется софтом, «вылеченным от жадности», совершенно непонятно, как можно работать со старой версией программного инструмента. А теперь представьте, что в инофирме вам начальник ответит примерно так: «Поскольку других денег у фирмы нет, то мы можем понизить вам зарплату или уволить кого-нибудь из вашей группы для того, чтобы заплатить за обновление софта. Текущая версия работает? Да! Сдадим проект, получим прибыль, расплатимся с кредитом и посмотрим, понадобится ли для следующего проекта новая версия. Или и дальше будем работать с этой версией». Так что, учтите, что возможно, у заказчика стоит более старый софт, на котором ваш проект может просто не запуститься. Так что еще раз напоминаю: составляя договор на исполнение работ с инофирмой, начинайте с конца. Что будет считаться успешным окончанием работы? Как она должна сдаваться и кому? В каком виде должны быть представлены файлы? На каком программном инструменте (с учетом версии) и где территориально будет происходить сдача работ? Какая операционная система должна стоять на том компьютере, где вы будете сдавать работу? Какие дополнительные программы должны быть установлены, а каких программ вообще не должно быть на таком компьютере? И это совсем не мелочь! Представьте, что вы получили замечание в процессе сдачи работы и хотите его исправить. Но вам говорят: «Нет! На этой машине нужных вам программ нет, и они не должны быть здесь установлены, так как это не оговорено в договоре!» Так что вместо того, чтобы быстро поправить проект и продолжить испытания, вам придется согласиться на перенос сроков испытаний. А это уже само по себе плохо!

   Или, например, другая ситуация. Прибор, который вы разработали, подключается к хост-компьютеру. И как вам кажется, для этого подойдет любой компьютер. То есть фирма делает свой прибор, а хост-компьютер предоставляет заказчик. Именно так рассуждал руководитель проекта на моей предыдущей работе. И что же получилось в действительности? Заказчик поставил свой компьютер. Естественно, на компьютер был установлен тот софт, который полагалось устанавливать на предприятии заказчика. В том числе и почтовые, и антивирусные, и еще какие-то «антишпионские» программы. А результат? Заказчик заявил, что хост не успевает в заданное время строить диаграммы. Однако было невозможно доказать, что это происходит из-за того, что хост занят фоновыми программами. Нет в документации соответствующего раздела! И прибор был признан не соответствующим требованиям задания, хотя изготовитель прибора неоднократно показывал заказчику, что хост-компьютер с отключенными фоновыми программами успевал выполнять заданную работу.

3. Самый главный вывод — проект должен быть выполнен в срок. Задержка в месяц или более приводит к краху фирмы, работающей на заемных деньгах! Вот это и есть самое страшное. Вы можете работать по вечерам и по выходным (что у меня и было) и выполнить и даже перевыполнить все поставленные лично вам задачи, но поскольку вся фирма не сдала проект в срок, то, увы. Фирма терпит банкротство и разваливается. Я уже не говорю о зарплате за последние месяцы, которую вы тоже никогда не увидите.

Теперь, когда основа сюжета описана, надо рассказать о технической политике.

То есть о том, как и какими идеями руководствуются разработчики при оптимизации реализуемого проекта.

Подъемные краны, политика и техническая политика

Когда-то, очень давно, еще при «старой власти», мне запомнился сюжет, который рассказывали по радио. Где-то, в одной из «дружественных» стран, как тогда говорили, то ли в Индии, то ли в какой-то из арабских стран дело было. Там в порт пришел пароход, и его надо было срочно разгрузить. Груз весил 12 тонн. А краны, которые были в том порту, рассчитаны только на подъем 10 тонн груза. Причем одни краны там были советские, а другие американские. Ну, и как вы уже догадались, сюжет развивался соответствующим образом. А иначе стали бы о нем говорить тогда по «нашему» радио? Американский кран не смог поднять тот груз. А вот советский кран, конечно, смог! Тут история о кранах была закрыта, и началась «политическая прокачка». Вот, мол, передовой советский кран! Не чета захудалому американскому. И так далее и тому подобное. Теперь-то мы это легко воспринимаем, не то что тогда. Но ведь дело здесь не в политике как в таковой, а дело в технической политике. Если у вас, дорогой читатель, найдется немного свободного времени, прочтите [2], не пожалеете. Чтобы понять, почему мы другие, придется начать издалека. (Увы, знаю, что страдаю этим, но ведь хочется все так подробно объяснить, чтобы не было таких вопросов: «А почему это так, может это все и не так?»)

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

А вот на другом берегу океана, в Штатах, никогда не было феодалов. И не было необходимости выполнять заказ только для какого-либо одного лица. Здесь мы не будем рассматривать американский госзаказ, ибо не он сформировал лицо американской промышленности. Но кто же тогда начал покупать продукцию, выпускаемую промышленностью? Ответ один — население. А для населения промышленная продукция должна соответствовать совершенно другим критериям.

Во-первых, продукция должна быть дешевой! Во-вторых, нет никакой необходимости, чтобы продукция была лучше, чем об этом заявлено при продаже. Ну и, наконец, продукция должна быть массовой. Ведь только массовая продукция при небольшой цене может принести большую прибыль. Вспомните автомобиль Форда — «жестяная Лиззи». При массовом производстве цена на него непрерывно снижалась (да-да, именно снижалась, трудно это понять тем, кто смотрит на отечественные авто), а качество улучшалось. И эти автомобили выпускались только черного цвета — это снижало издержки на покраску. Так как же в таком случае предприятие будут гордо именовать? Конечно, вот так — «№ 1 в мире по выпуску и продаже .».

А теперь давайте вспомним про историю с кранами. Что бы о ней рассказали по американскому радио? Я думаю, что сказано было бы так: «Американский кран показал, что он, несомненно, лучше советского, именно потому, что он не смог поднять тот груз, на который он не был рассчитан. Это значит, что он оптимально сконструирован, в нем не заложено ничего лишнего, следовательно, он оптимизирован еще и по цене. А советский кран спроектирован довольно грубо, в него заложены слишком большие допуски, это значит, что он в изготовлении дороже». Мало того, далее американское радио, сравнивая советский и американский краны, продолжило бы так: «Если вы покупаете кран, способный поднимать 12 тонн, и используете его вместо крана на 10 тонн, то вы платите больше. Вы необоснованно теряете деньги!».

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

Выводы по этому разделу такие: будьте готовы к тому, что руководитель проекта проверит каждую мелочь и, если найдет что-либо, на чем можно будет сэкономить, то будьте уверены, вам придется переделывать каждый узел, где вы не смогли убедительно объяснить, что «вот без этой детали то-то и то-то будет не так». Высказывания о том, что «это рекомендованная схема» или «все так и делают», скорее всего, не будут приняты. Причем переделывать вы будете в свое личное время.

Теперь, когда основа сюжета описана, нужно рассказать об исполнительской дисциплине.

«Крупные по пять, но вчера»

Любой разработчик знает, что дело наше сложное и без ошибок не обходится. Все дело в том, кто и как эти ошибки исправляет. Ну и, конечно, вы помните фразу, полную сожаления о том, что «вчера» ушло безвозвратно: «Крупные по пять, но вчера». Так как же обстоят дела с этим у «них» и у «нас»? Как это раньше было у «нас», наверное, еще кое-кто помнит. Отделы стандартизации, нормо-контроли, приемки заказчика. И хоть умри, но весь комплект КД — конструкторской документации — должен был сдан в архив предприятия к моменту окончания разработки. Не успели немного? Откорректируем срок сдачи чертежей в архив. Переделали схему или конструкцию кардинально, тоже ничего страшного. Сделали «Извещение на изменение». «Задел доработать» — и можно прилепить сверху проводки. Или «Задел доработке не подлежит» — и заказываются новые модули. То есть вся документация выполнена всегда на 100%, а иначе и быть не может. Но сроки выполнения обычно устанавливались не жестко. И всегда можно было что-то поменять и «подкорректировать» уже потом, когда официально вы занимались уже другой темой.

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

А теперь представим «их» индуса или китайца у «них» в компании. И он на «примерно английском языке» пишет такое же техническое описание. Как вы думаете, станет ли он вообще что-либо переделывать, если срок выполнения работы уже кончился? Я отвечу на это абсолютно точно. Если есть свободный вечер или свободные выходные, то, может быть, и станет, если этот парень трудоголик и сильно хочет заработать себе повышение. Или если он сам хозяин этой фирмы и работает на свой карман. Но основной ответ, для большинства случаев, будет таков: «Да ему и в голову не придет что-либо переделывать, если срок выполнения этой работы уже истек!» Я прекрасно помню, как приходил доктор Алекс и на шотландском английском задавал мне вопрос о том, почему я взялся переделывать однажды сделанную часть проекта.

Мой учитель и наставник А. М. Полонский в 1976 г. учил меня так: «Ты можешь делать работу очень качественно, но очень медленно, и она никому не будет нужна, потому что она сделана очень медленно. Или же ты можешь сделать свою работу очень быстро, но очень плохо, и тогда твоя работа не будет никому нужна, потому что это будет сплошная халтура. Надо всегда выбрать в меру хорошую работу, но и сделать ее как можно быстрее!»

Вот именно так и работают сейчас все инофирмы. И когда мои коллеги находят ошибки в даташитах, а это случается довольно часто, то я теперь уже и не удивляюсь этому. Да, я именно поэтому и стараюсь применить «продвинутые» (не люблю этот термин) приемы проектирования, такие, чтобы заведомо избежать ошибок. Посмотрите мои статьи о самодельных программных инструментах. И именно поэтому я также тогда старался вести 3 файла одновременно: вериложный файл, С++ файл и техническое описание, поскольку применение такого приема позволяло избегать ошибок и делать исправления. Но все же были случаи, когда это не помогало.

Вот, к примеру, я знаю, что статический автомат с большим числом состояний — это верный путь к провалу. И когда мне поручили сделать управляющий автомат в ПЛИС, то я через некоторое время понял, что автомат будет избыточно сложный и трудно отлаживаемый. Я пошел по принципиально другому пути и сделал самодельный микроконтроллер, так как для «фирменного» микроконтроллера в ПЛИС деньги на лицензию не были предусмотрены, а проекты с самодельными микроконтроллерами я уже умел делать. И когда я начинал его разрабатывать и программировать, то считал, что 1К слов команд будет вполне достаточно. Соответственно и был выбран объем памяти для микроконтроллера, и этому же объему соответствовали поля в командах, при помощи которых производилась адресация памяти и регистров. Но в процессе разработки коллеги «навернули» мне еще довольно много алгоритмов, которые надо было реализовать. В результате в памяти команд осталось только несколько свободных ячеек. По моим тогдашним понятиям надо было срочно переделывать адресную сетку и увеличивать объем памяти команд, благо в ПЛИС было достаточно незадействованных ресурсов. Что я тогда и начал делать в спешном порядке. Но через некоторое время прибежал доктор Алекс и начал меня буквально допрашивать: «Зачем вы начали переделку проекта?» «Я понимаю, что, возможно, при испытаниях потребуются еще изменения в софте, но ведь сегодня проект уже работает!» — вот что он пытался мне втолковать, поскольку никак не мог понять мои объяснения. А я не мог понять, как можно было начинать приемосдаточные испытания у заказчика, не имея никакого резерва по памяти. Еще надо добавить, что при поступлении на работу коллеги сразу же меня предупредили о том, что если я не сумею объяснить доктору то, что я сделал за сегодня, то меня быстро уволят. Вот уж где прогресс в разговорном и письменном английском сказался довольно быстро!

Выводы по этому разделу такие: чтобы успешно работать на «них», нужно не только хорошо работать, это здесь даже не обсуждается. Нужно еще и понимать то, как построена работа. Что можно делать по «их» правилам, а что совершенно нельзя.

Армейская шутка о дубах гласит следующее: «Все дубы, и все шумят»

В этом разделе пойдет речь о еще одном различии между «нами» и «ними». А именно об иерархии взаимоотношений и о начальниках и подчиненных.

Классики учили, что «бытие определяет сознание». И это действительно так! Давайте рассмотрим это более тщательно на примерах. Как устроены «наши» «разработческие конторы»? Ну, хотя бы для малых и средних предприятий.

Проследим «нашу» иерархию: «директор», «зам. по науке», «начальник отделения», «начальник отдела», «начальник лаборатории», «руководитель группы», «сотрудник группы». Все до боли знакомо. Все застыло намертво, навеки (или до очередного сокращения). Как ведется проект при такой организации работ? Если проект небольшой, то его ведет «руководитель группы» вместе со своими сотрудниками. Если проект выходит за рамки одной группы, то к нему подключаются несколько групп из разных лабораторий. Или же вся лаборатория объединяется и ведет проект целиком. Если проект еще больше, то производится объединение лабораторий, отделов и так далее. При этом, подчеркнем еще раз, что состав групп от проекта к проекту практически не меняется. Есть группа, и она под началом своего руководителя и работает. При такой организации работ руководитель группы всегда заинтересован, чтобы его сотрудники были как можно более технически грамотными. В идеале, чтобы его сотрудники были «универсальными солдатами», поскольку обычно никого дополнительно руководитель группы себе в помощь получить не мог. И соответственно руководитель группы всеми правдами и неправдами сопротивлялся тому, чтобы отдать «своего» сотрудника, пусть даже и временно, в другую группу. Наоборот, они всегда стремились набрать как можно больше людей, чтобы потом «перерасти» в «лабораторию». А это и новые ставки, и новое положение. Так что же для этого было нужно делать? Для того чтобы все порученные работы выполнялись в срок и с высоким качеством, руководителю группы приходилось обучать своих сотрудников. Помните высказывание советских времен: «Забудьте все, чему вас там в институте учили, и давайте учитесь заново на месте». Не могу сказать, что это было плохо. Такая система взаимоотношений, там, где она практиковалась, позволяла достигать хороших результатов. Могу сказать, что во ВНИИЭП, где в 1976 г. я начинал свою карьеру разработчика, мне сильно повезло с этим. Коллектив лаборатории был очень дружным, взаимоотношения были очень хорошие. Мы всегда помогали друг другу в работе, вместе отмечали праздники, ходили на демонстрации. Тут можно было бы продолжить, но приходится остановиться.

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

Теперь рассмотрим, как строится иерархия у «них».

«Их» иерархия: «директор», «руководитель проекта», «исполнитель». Или же для больших проектов вот так: «директор», «руководитель проекта», «руководитель группы», «сотрудник группы». Нет ни отделов, ни лабораторий с фиксированным составом исполнителей. Есть только одно самое главное понятие — ПРОЕКТ. И под него выделяются исполнители. А это значит, что есть, как говорят программисты, «куча» сотрудников, и из этой «кучи» выбираются исполнители для различных проектов. То есть вчера исполнитель работал в составе «бригады», которая делала проект Х. И когда проект Х успешно завершился, то вся эта «бригада» расформировывается. Далее ее участники могут быть привлечены к другому проекту, например Y, или уволены за ненадобностью. Примеров тут не привожу, их теперь и так кругом достаточно.

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

Теперь надо добавить еще пару слов о руководителе проекта. Это тот человек, который все знает о проекте. И он совсем не стремится, чтобы об этом проекте все исполнители знали как можно больше. Каждый исполнитель должен знать только ту часть проекта, над которой он работает, и не более. Зачем тратить время на объяснения? Ведь если исполнитель «дорастет» до уровня руководителя проекта, то кого фирма выберет для руководства следующим проектом?

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

О коммерческой тайне у «них»

Как сказано выше, «их» фирма никогда не предоставит рядовому исполнителю полную информацию о проекте. Мало того, мы знаем, что наибольшая прибыль получается только в том случае, когда фирма первой выходит на рынок. Давайте рассуждать так, как положено у «них»: разработали новый формат записи на DVD, такой, «как нам интересен», и быстро вышли с ним на рынок. Пока конкуренты догоняют, мы уже успеваем заполонить рынок своей продукцией. Значит, мы должны сделать все возможное для того, чтобы не дать конкурентам себя догнать. Засекретить все, что можно, и самое главное — запретить сотрудникам «разглашать». У них это называется NDA. Вот именно поэтому, когда я показал доктору Алексу журналы с моими статьями, то он тут же в договор внес пункт о запрете публикаций чего-либо связанного с новой работой. Точно с таким же отношением я сталкивался и в некоторых других «разработческих» фирмах. Лично я это поддерживаю. Если вы хотите получить результат какой-либо работы, то заплатите за нее. Конечно, многие «наши» и не «наши» сейчас сильно развращены обилием материалов, выложенных в Интернете на сайтах открытых проектов. Но здесь надо всегда иметь в виду, что выкладываются либо очень сырые материалы, либо то, что не представляет существенной ценности.

Заключение

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

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

Литература

1. www.iosifk.narod.ru
2. Мак-Нил У. В погоне за мощью. Технология, вооруженная сила и общество в XI-XX веках / Пер. с англ. Т. Ованнисяна. М.: ИД «Территория будущего», 2008.