Письмо в редакцию
+
...возникающих в процессе разработки и внедрения ПО в России
Кирилл Захаров
Пригласили американские ученые для опытов троих студентов окрестных колледжей: американца, немца и русского. Дали каждому по десять стеклянных шаров, посадили в герметичные камеры и стали ждать. Через неделю заглядывают в камеры.
Американец: шары подбрасывает, ловит, катает. Резюме: произошел резкий скачок физического развития.
Немец: шары измеряет, кучками складывает, формулы пишет. Резюме: произошел резкий скачок умственного развития.
Русский: сидит на полу, перед ним осколки ОДНОГО шара, остальных шаров нет.
Ученые открывают камеру и спрашивают русского: “Шары-то где?”. А тот им грустно так отвечает: “Про@#$л +”.
Из народного юмора
Насколько я понял из текста письма, опубликованного в PC Week/RE, № 41/98, с. 22 (его название спародировано выше), уважаемый г-н Кулешов (его автор) занят приблизительно тем же, чем большинство программистов в этой стране, - разработкой финансово-экономических и управленческих программных комплексов. Это занятие (видимо, многолетнее) исторгло из его души крик, читателями которого мы все стали.
Автор излагает десять причин того, почему ему плохо живется, и чисто по-русски пытается свести свои личные проблемы к проблемам страны. Не стану останавливаться на вполне очевидной мысли, что возникающие проблемы надо решать, а не кричать о них на весь свет. На мой взгляд, опубликованное письмо является типичным образчиком “российского менталитета” в области подходов к разработке ПО, и рассматривать его надо именно под этим углом.
Заблуждение первое: низкая квалификация заказчика. Хочется сразу задать вопрос: квалификация в чем? В своем бизнесе он кому угодно сто очков вперед даст. А в нашем бизнесе он и не обязан ничего понимать, он пришел к нам и сказал: “Сделайте мне хорошо!”. А как сделать - это наша проблема.
Автор, видимо, подменяет понятие “заказчик вообще” на “руководство ИТ-подразделения заказчика”. Но даже в этом случае взаимодействие с ИТ-подразделением заказчика - это проблема исполнителя, а не заказчика. Большинство ИТ-руководителей очень легко заинтересовать в успехе проекта: продвижением ли по службе, пунктом ли в резюме “успешно внедрил”, дополнительными ли знаниями, деньгами ли - не важно, главное, можно. Мне лично попался только один “непробиваемый” тип ИТ-руководителя (он же самый опасный для проектов): молодой (28-33), энергичный, грамотный - в объеме, необходимом для убеждения начальства в своей правоте, и+ “сидящий на игле” какого-либо крупного дистрибьютора, из тех, что работают с начальниками отделов автоматизации как с “физическими лицами”. Вот таким людям действительно ничего не надо, кроме постоянно растущего процента “личной скидки”. Но и с этим тоже можно бороться, заинтересовав похождениями такого горе-руководителя службу собственной безопасности компании и получив, кстати, контракт на аутосорсинг ИТ-менеджмента в этой компании.
Заблуждение второе: низкая востребованность современных технологических решений. Заказчику все равно, современное или не современное технологическое решение заложено в систему, ему важно знать, сколько денег и в какой срок он должен выплатить и какую выгоду он от этого получит.
Если для решения проблем заказчика необходимо просто перестроить существующий бумажный документооборот с редкими включениями Excel, Word и “1С”, об этом надо честно сказать, а не пытаться продать ему R/3. Этот подход гарантирует, что как только, заказчик дорастет до автоматизации - он придет к тебе. САМ!
Не стоит выделять в стоимости проекта разработку, базовые ПО и оборудование, заказчику интересна конечная сумма.
Не стоит ориентироваться на продукты компании Microsoft. Из-за их грошовой стоимости практически не остается места для маневра скидками между ценой конечного пользователя и дилерской.
Для “совсем бедных”: практически все производители СУБД перенесли свои продукты под Linux, который вообще распространяется бесплатно.
Заблуждение третье: недостаток аналитиков и проектировщиков. Автор, видимо, предполагает каждую разработку начинать с нуля.
Практически все заказчики хотят одного: управленческого учета реального бизнеса в режиме “виртуального холдинга” с регулярным сбором балансов по всем конторам для сдачи в налоговую инспекцию. Где тут место аналитикам и проектировщикам? Особенно на +надцатом проекте. К этому времени уже должна существовать методология общения с заказчиком на понятном ему языке, например, в терминах документов, их состояний и генерируемых проводок при изменении состояний. А аналитик (один) сидит в офисе и дорабатывает эту методологию в случае возникновения ситуаций, в которых методология не срабатывает.
Нет методологии? Так чья это проблема - ваша или страны?
Заблуждение четвертое: постоянное увеличение затрат на повышение квалификации. Не надо использовать некорпоративные средства разработки. Не надо писать на Си/Cи++ интерфейс к БД, у каждой СУБД (кроме MS) существует “родной” инструмент, который позволяет писать, не думая об особенностях функционирования Grid. Да, с их помощью невозможно построить Pure MS интерфейс. А кто сказал, что этот интерфейс идеален для работы с данными? Нормальный интерфейс - это текстовое окно с действиями по номерам пунктов в меню и/или “горячим” клавишам. Банковской операционистке окна ни к чему, ей надо “вколотить” свою тысячу документов в день.
Не надо использовать не-SQL СУБД, сейчас уже есть продукты, пригодные даже для микропроектов и встраиваемых систем.
Не надо идти на поводу у компаний, бизнес которых построен на одновременном выпуске трех несовместимых между собой версий одного продукта.
Пока, слава Богу, есть выбор.
Заблуждение пятое: неправильный выбор средства разработки. Ваш выбор - это ваш выбор (см. заблуждение четвертое). Я, например, использую PowerBuilder четвертый год подряд. В приложениях есть куски кода, перенесенные из версии 4 (сейчас рабочей считается версия 6.5). Я знаю, что у той же компании есть другие продукты, более мощные и современные, но до тех пор, пока в них не будет реализована функциональность, имеющаяся в PowerBuilder, я не перейду на эти продукты. Совместимость дороже новых возможностей.
Заблуждение шестое: недостаток информации об отечественных разработках. О каких разработках идет речь? Если о готовых системах, то либо я ничего не понял, либо автор забыл алфавит. Все специализированные журналы, все выставки забиты одним и тем же: “1C”, “Парус”, “Галактика”, “БОСС”, “Омега”, “RS-*”, “Диасофт”, “Програмбанк”. И много кто еще. Технологии вскрываются за пару часов сидения за терминалом на выставке или просмотра демоверсии системы, особенно если где-нибудь рядом есть SQL-трассировщик.
А насчет средств разработки+ Я знаю один более или менее успешный пример - “Эпсилон-технолоджи”. Но вот нюанс: этой фирме как разработчику средств разработки 2-3 года от роду. А если она разорится, перепрофилируется или еще что-нибудь? Между прочим, в начале 90-х было около десятка компиляторов Cи/Cи++. Где они все? Выжили только те, что производились фирмами, основной бизнес которых был весьма далек от “разработки средств разработки”.
Заблуждение седьмое: неуправляемые программисты. Как известно, есть программисты, программисты и программисты+ И не надо складывать все яйца в одну корзину.
Есть технологические бустеры, их хлебом не корми, дай разобраться в новом софте, но как только стадия изучения пройдена - интерес пропадает напрочь. Максимум, что можно от них требовать, это передать свои знания другой группе. Постоянное содержание в штате таких людей большого смысла не имеет, но сделать так, чтобы с новыми идеями они приходили к тебе, - дело чести любого руководителя.
Есть “упаковщики” - они очень хороши, когда надо оформить и довести до совершенства сырые идеи “бустера” и передать их в документированном виде на завод - “кодерам”. Кстати, из них получаются классные менеджеры. “Кодерами” ведь тоже надо управлять.
Ну а “кодер” - он и есть “кодер”, у него оплата сдельная, ему бузить некогда, а забузил - иди на ту помойку, где тебя подобрали.
Между прочим, такая схема позволяет делать то, на чем сломалось большинство “старых” программистских фирм (тех, что начинали на Clipper), - реализовывать системы на новых технологиях, не прекращая поддержку старых систем. Просто рядом с существующей “пирамидой” строится новая. В рамках этой пирамиды людям есть куда расти и чего хотеть, а старая дает работу тем, кто уже “не может” или “не хочет”, и будет давать еще лет пять.
Заблуждение восьмое: “вычитание стоимости”. Если ты акционер фирмы, но не можешь проконтролировать хотя бы финансирование “своего” проекта+ продай свою долю и садись на зарплату, а если уже сидишь, то финансирование вообще не твоя забота, твоя забота - в срок сдать проект.
По моим наблюдениям, ситуация как раз обратная. Программистские коллективы обычно финансируются за счет основного бизнеса компании, может быть, плохо и мало, но бесконечно долго и независимо от результата.
Заблуждение девятое: “пополнение знаний”. Упирается либо в заблуждения четвертое и пятое, если по завершении проекта надо начинать “программировать” новый, либо в седьмое, если по окончании проекта надо продолжать пополнять знания в области программирования, хотя лучше бы - в области менеджмента.
Заблуждение десятое: “хорошая пицца”. Если человек умудрился совершить все вышеперечисленные ошибки и все еще мечтает о хорошей пицце, то он либо оптимист, либо идиот. Проект-то уже провалился, отдел разогнали, и надо искать не пиццу, а новую работу, причем там, где еще не знают о его предыдущем провале.
К автору можно обратиться по адресу: cez@aha.ru.
