R&D без дыма из ушей
Apr. 7th, 2010 12:21 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
thedeemonНекоторые вот жалуются, что в R&D (research & development) так все сложно организовать, что нельзя угадать сроки и оттого у ресерчеров идет дым из головы 24 часа в сутки, лишая их семейной и всяческой другой жизни и грозя дуркой и лоботомией в ближайшем будущем, а менеджеры снимают стресс литрами, портя себе печень и настроение. Мне же посчастливилось поучаствовать в нескольких R&D проектах, где все было иначе.
1. Была у нас на факультете такая лаборатория машинной графики, а в ней - так называемая видеогруппа (собственно, и сейчас есть, но мне проще писать в прошедшем времени, т.к. наблюдал я это несколько лет назад, а как там сейчас - не знаю). Группа состояла в основном из студентов и аспирантов, которые двигали вперед науку, получая свои курсовые, дипломы и кандидатские. Одновременно с этим видеогруппа являла собой коммерческую компанию с иностранным именем и сайтом на нерусском языке. И значительная часть проектов делалась не просто так, а в рамках контрактов с такими конторами, как Intel, Samsung, Real Networks и др. Часть контрактов шла через университет, что было выгодно и престижно университету, но не слишком выгодно исполнителям, а часть - через это свое юр.лицо. Часть разработок (что были сделаны не в рамках контрактов) выкладывалась в свободный доступ в качестве бесплатных для некоммерческого использования программ (обычно плагинов для VirtualDub'a, Photoshop'a и т.п.), а часть оставалась коммерческим секретом и продавалась большим заказчикам. Руководил группой Дима Ватолин, основатель compression.ru, человек, прекрасно разбирающийся в предметной области и всегда способный быстро понять ситуацию и назвать десяток путей дальнейшего развития. Я очень многому у него научился, считаю его своим учителем и жалею, что поздно с ним познакомился (я учился на другой кафедре и настоящим членом видеогруппы никогда не был, работая с ними уже после окончания университета).
Как там все происходило. Обычно сначала в рамках чистой науки рождался какой-то зачаток технологии, первая версия. Иногда она доводилась до уровня работающего плагина, иногда просто оставалась неким тормозным иногда работающим кодом на матлабе, с помощью которого удалось сделать несколько красивых картинок, которые выставлялись на сайте лаборатории с описанием технологии. Когда компания-заказчик заинтересовывалась технологией, с ней заключался контракт на доработку технологии (тут как раз R&D) с последующей передачей исходников и прав (иногда эксклюзивных, но если получалось сторговаться, то неэксклюзивных). И тут ключевыми были два фактора:
1. Никогда не обещать слишком многого. Быть реалистами. Если у заказчика есть хорошие деньги, это не значит, что нужно сразу обещать сделать вечный двигатель или убийцу H.264, даже если мы представляем как это сделать.
2. Делать сроки большими, с запасом. Никогда это не было "поставить рекорд за две недели". Обычный контракт включал 6-12 месяцев на разработку, даже если технология была "почти готова".
Понятно, что многие исполнители были студентами, которые не работают full time, да еще и сессии у них случаются, поэтому сроки такие длинные.
Дальше начиналась работа. Кто-то работает в лаборатории, кто-то дома. Каждый день каждый участник проекта должен был прислать письмо с несколькими короткими списками. В первом списке - что было сделано сегодня и сколько потрачено времени в часах. Второй список - что планируется сделать завтра. Третий - более глобальные планы. И четвертый - текущие проблемы. Везде коротко, одной строкой. Отчеты были видны всем участникам проекта. Составить такой отчет - дело минутное, но как же он организует! Получается, что у каждого студента-раздолбая есть актуальный todo-list, и есть необходимость вписать что-то в раздел "сделанное". Вместе это создавало движущую силу, не давало уйти надолго в бесплотные размышления или запой. Кроме того, руководитель проекта своевременно видел возникающие проблемы и мог тут же помочь в их решении, вместо того, чтобы узнать о них за неделю до дедлайна.
Раз в неделю участники проекта собирались вместе для большей синхронизации и определения текущих проблем и задач. Это особенно было актуально для меня, т.к. я тогда постоянно работал в другом месте, и на факультете кроме как для этих встреч не бывал.
Кроме того, для всей группы еженедельно устраивался семинар, где люди делились полезным опытом по инструментам. Кто расскажет про матлаб, кто про маткад, кто про CVS, кто про IPP. Это тоже было весьма полезно.
И вот, благодаря такой постепенной, но непрерывной работе, и благодаря достаточно длинным срокам, ресерч проходил успешно без всяких красных глаз и закипания мозгов.
2. Сейчас у меня собственная компания, занимающаяся разработкой и продажей софта и технологий. Большую часть времени ресерч делается для себя, для улучшения собственных продуктов (и тут никаких дедлайнов и запарок нет, когда будет готово, тогда и хорошо), но время от времени к нам обращаются другие компании, которые хотят ту или иную технологию, так или эдак доработанную. Т.е. это разработка не с нуля, но не всегда с известным результатом - может, получится добиться заданной цели, а может и нет. И в таких ситуациях меня спасают те же два принципа: не обещать слишком многого и брать сроки с запасом. В итоге и заказчик получает все, что обещано, и у меня остается достаточно времени на семью, путешествия, развлечения и занятия для души, вроде того конпелятора и статей про карри с бананами и эндофункторами.
1. Была у нас на факультете такая лаборатория машинной графики, а в ней - так называемая видеогруппа (собственно, и сейчас есть, но мне проще писать в прошедшем времени, т.к. наблюдал я это несколько лет назад, а как там сейчас - не знаю). Группа состояла в основном из студентов и аспирантов, которые двигали вперед науку, получая свои курсовые, дипломы и кандидатские. Одновременно с этим видеогруппа являла собой коммерческую компанию с иностранным именем и сайтом на нерусском языке. И значительная часть проектов делалась не просто так, а в рамках контрактов с такими конторами, как Intel, Samsung, Real Networks и др. Часть контрактов шла через университет, что было выгодно и престижно университету, но не слишком выгодно исполнителям, а часть - через это свое юр.лицо. Часть разработок (что были сделаны не в рамках контрактов) выкладывалась в свободный доступ в качестве бесплатных для некоммерческого использования программ (обычно плагинов для VirtualDub'a, Photoshop'a и т.п.), а часть оставалась коммерческим секретом и продавалась большим заказчикам. Руководил группой Дима Ватолин, основатель compression.ru, человек, прекрасно разбирающийся в предметной области и всегда способный быстро понять ситуацию и назвать десяток путей дальнейшего развития. Я очень многому у него научился, считаю его своим учителем и жалею, что поздно с ним познакомился (я учился на другой кафедре и настоящим членом видеогруппы никогда не был, работая с ними уже после окончания университета).
Как там все происходило. Обычно сначала в рамках чистой науки рождался какой-то зачаток технологии, первая версия. Иногда она доводилась до уровня работающего плагина, иногда просто оставалась неким тормозным иногда работающим кодом на матлабе, с помощью которого удалось сделать несколько красивых картинок, которые выставлялись на сайте лаборатории с описанием технологии. Когда компания-заказчик заинтересовывалась технологией, с ней заключался контракт на доработку технологии (тут как раз R&D) с последующей передачей исходников и прав (иногда эксклюзивных, но если получалось сторговаться, то неэксклюзивных). И тут ключевыми были два фактора:
1. Никогда не обещать слишком многого. Быть реалистами. Если у заказчика есть хорошие деньги, это не значит, что нужно сразу обещать сделать вечный двигатель или убийцу H.264, даже если мы представляем как это сделать.
2. Делать сроки большими, с запасом. Никогда это не было "поставить рекорд за две недели". Обычный контракт включал 6-12 месяцев на разработку, даже если технология была "почти готова".
Понятно, что многие исполнители были студентами, которые не работают full time, да еще и сессии у них случаются, поэтому сроки такие длинные.
Дальше начиналась работа. Кто-то работает в лаборатории, кто-то дома. Каждый день каждый участник проекта должен был прислать письмо с несколькими короткими списками. В первом списке - что было сделано сегодня и сколько потрачено времени в часах. Второй список - что планируется сделать завтра. Третий - более глобальные планы. И четвертый - текущие проблемы. Везде коротко, одной строкой. Отчеты были видны всем участникам проекта. Составить такой отчет - дело минутное, но как же он организует! Получается, что у каждого студента-раздолбая есть актуальный todo-list, и есть необходимость вписать что-то в раздел "сделанное". Вместе это создавало движущую силу, не давало уйти надолго в бесплотные размышления или запой. Кроме того, руководитель проекта своевременно видел возникающие проблемы и мог тут же помочь в их решении, вместо того, чтобы узнать о них за неделю до дедлайна.
Раз в неделю участники проекта собирались вместе для большей синхронизации и определения текущих проблем и задач. Это особенно было актуально для меня, т.к. я тогда постоянно работал в другом месте, и на факультете кроме как для этих встреч не бывал.
Кроме того, для всей группы еженедельно устраивался семинар, где люди делились полезным опытом по инструментам. Кто расскажет про матлаб, кто про маткад, кто про CVS, кто про IPP. Это тоже было весьма полезно.
И вот, благодаря такой постепенной, но непрерывной работе, и благодаря достаточно длинным срокам, ресерч проходил успешно без всяких красных глаз и закипания мозгов.
2. Сейчас у меня собственная компания, занимающаяся разработкой и продажей софта и технологий. Большую часть времени ресерч делается для себя, для улучшения собственных продуктов (и тут никаких дедлайнов и запарок нет, когда будет готово, тогда и хорошо), но время от времени к нам обращаются другие компании, которые хотят ту или иную технологию, так или эдак доработанную. Т.е. это разработка не с нуля, но не всегда с известным результатом - может, получится добиться заданной цели, а может и нет. И в таких ситуациях меня спасают те же два принципа: не обещать слишком многого и брать сроки с запасом. В итоге и заказчик получает все, что обещано, и у меня остается достаточно времени на семью, путешествия, развлечения и занятия для души, вроде того конпелятора и статей про карри с бананами и эндофункторами.
