Почти все о программных разработках АСКОНа. Часть I

Точно не CTO, но дело, наверное, не в названии? Действительно, я руковожу разработкой ПО в АСКОН.

Спасибо за провокационный вопрос :) Давай-ка, сразу разделим все разработки на регулярное производство и новые проекты. Производство – это стабильный выпуск очередных версий. Здесь не очень разгуляешься с авторитарностью: требования на версию должны собираться у клиентов, анализироваться, систематизироваться, ранжироваться и балансироваться по ресурсам. Впрочем, так не было ни разу )

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

Формально — не имею права. Неформально — не имею желания. Все конкурирующие концепции на версию прорабатываются специалистами. Я не считаю возможным демотивировать их, отбросив все аргументы. Убеждать — да. Но, к сожалению, это не всегда удается. Правда, есть много возможностей в рабочем порядке пересмотреть приоритеты. Разработка ПО — это всегда исследование, для которого надежные прогнозы трудозатрат отсутствуют по определению, а исходные требования меняются самым причудливым образом. Так что поводов для реприоритезации обычно хватает.

У меня нет выделенной группы исследователей-экспериментаторов. Чего-то типа labs. Но в каждом подразделении есть пара-тройка ребятишек (условно: иным уже за сорок :)), которые всегда нацелены на поиск. Это не прописано в их должностных инструкциях. Речь идет о сугубо внутренней мотивации. Люди сами ставят задачи и находят решения. В таких случаях мы почти всегда доводим проект до успешной реализации. Подобная организация работ делает каждый проект востребованным, конкретным и понятным, снижая почти до нуля риск отработать на корзину.

Именно по этому сценарию развивались недавние события и с VDM (Variational Direct Modeling – совместный проект АСКОН-ЛЕДАС-Bricsys), и с Lightworks Artisan, и с параллельным перестроением ассоциативных видов, и с методикой нисходящего проектирования, и с КОМПАС@Linux, и с 64-разрядными дистрибутивами, и с АПМ FEM. Другой пример: мобильный ЛОЦМАН-ПГС – это тоже внутренняя инициатива, поддержанная продуктовым маркетингом. Кстати, всё перечисленное представлено здесь, на Форуме.

Он вызрел буквально на глазах, стараниями многих людей.

Хм... Без. Я очень осторожно отношусь к формализованным обоснованиям технико-экономического толка. В нашей отрасли энтузиазм или его отсутствие, а еще квалификация людей определяют всё. Один и тот же продукт может быть успешным или наоборот, в зависимости от вовлеченных персонажей. С «буйными» иногда очень непросто, но никогда не скучно – факт :) И еще это безумно интересно. Простыми таблицами такое не обсчитать, а значит, управленец классической школы неизбежно ощутит дискомфорт. Но много ли толка от комфортного управления, которое не имеет отношения к реальности? А реальность не бывает простой. И еще она всегда побеждает любые планы.

Да, это — проблема. Ресурсы, а не то, что ты подумал  Списка работ «впрок, на всякий случай» мы действительно не держим. Когда потребность масштабных изменений назревает, запускается особая процедура «инициации сверху». Это случается примерно раз в три года. Здесь риски уже неизмеримо больше и вероятность успеха не превышает половины.

Уверен, что если работать «впрок», выход годного драматически упадет, т.к. на старте проект не будет ни востребованным, ни конкретным, ни понятным. Скажешь, что нужна же проактивность, или, что оставшиеся 10% могли бы привести к прорывным (в терминологии Кристенсена) инновациям? Может быть... Но какова цена? Про ресурсы уже говорили, а еще подумай, чего стоит вернуть к нормальной жизни девять из десяти перемолотых инновационным молохом специалистов. При нашем-то рынке труда, о котором ты знаешь не по-наслышке...

Некоторые проекты идут особенно трудно, вплоть до расформирования команд. Иные удается спасти, например, реорганизацией. За крупные венчурные проекты переживают многие, включая Совет Директоров. Сейчас в оперативное управление Совет почти не вмешивается, но все его члены не чужды разработке. Это определяет глубину погружения в проблематику.

Около двухсот вместе со студентами. Это аналитики, программисты, тестировщики, технические писатели, специалисты технической подержки, группа локализации. Без сотрудников back-office, т.к. разработка традиционно пользуется его услугами из общего пула.

Да, почти сотня в Коломне, сорок в Питере, тридцать три в Кургане, десять в Гродно, восемь в Минске, шестеро в Нижнем и по одному в Москве, Самаре и подо Львовом. Весело, правда? :) Предмет моей особой гордости — среди них нет никого, кто не работал бы на production. Даже код Татьяны Янкиной, одного из основателей АСКОН, руководителя коломенского CAD-подразделения, есть в каждой версии КОМПАС-3D.

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

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

Я - инженер-механик, выпускник питерского Военмеха. После окончания проработал четырнадцать чудных лет на Дальнем Востоке. Сначала конструктором, потом технологом, затем снова конструктором, уже главным... После чего опять приехал в Питер.

Отнюдь. Послезавтра – «всего» одиннадцать лет моей работы здесь. Хотя, для многих это неотличимо от стажа основателей, а для новичков, полагаю, мы все в равной степени – деды 

Немало, но я хочу отметить крупные новинки, которые выделяются с точки зрения пользовательской ценности:

• Работа с исполнениями изделия в едином 3D-документе, плюс связанные групповые спецификации
• Размеры в 3D-операциях и технические требования в модели - т.н. PMI,
• Перестроение модели с использованием назначенных конструктором полей допусков.

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

Не только думаем, но делаем. Однако, мы изрядно утомили читателя :) Давай вернемся к теме после перерыва?