Продолжаем разговор
Михаил Донской
В PC Week/RE, № 41/98, с. 22 было опубликовано письмо в редакцию “Топ 10 проблем и неприятностей...”, посвященное разработке и внедрению ПО в России. Поскольку этим видом деятельности я занят уже много лет, то начал читать с интересом, пока не понял, что жалуется автор, в сущности, на себя. Ему бы стоило только посочувствовать, если бы не опасение, что молодые читатели воспримут эту шутку за чистую монету.
Прежде чем обсуждать письмо, давайте ответим на главный вопрос - в чем суть бизнеса заказного ПО (хоть в России, хоть у черта на куличках). На мой взгляд, в продаже квалифицированного труда разработчиков программного обеспечения людям, у которых нет квалификации или ресурсов для самостоятельного выполнения нужной работы.
Вопрос второй - из чего складывается квалификация разработчиков? На мой взгляд, из умения правильно поставить задачу, выбрать адекватные инструментальные средства и, главное, выполнить работу качественно и в срок. Исходной информацией здесь служит проблема заказчика, а не поставленная им задача. Заказчик согласен тратить свои деньги на решение этой проблемы, а не на то, чтобы самому ставить и решать задачу.
Бизнес заказного ПО выгоден для разработчиков только тогда, когда в их арсенале находится ряд готовых типовых постановок и решений. В этом кроется и подвох для заказчика, когда ему навязывают средства, не самые подходящие для решения его задачи, но уже имеющиеся у разработчика. И единственный способ избежать этого подвоха - опираться на репутацию разработчика и его предыдущий опыт. Отсюда и естественное разделение рынка заказного ПО на сектора - банковский, торговый и др.
Главный этап работы над заказным ПО - составление проекта (или по старой терминологии - технического задания). Проект должен включать все данные, необходимые заказчику для принятия решения о заказе: стоимость, требуемые ресурсы, сроки, конкретные результаты и все это - в терминах заказчика. В проект должны также включаться сведения о технологических решениях с подробным обоснованием - почему именно они были выбраны и какую долю стоимости проекта они составляют. Дело заказчика соглашаться с этим проектом или отвергнуть его. После утверждения речь уже пойдет только о реализации проекта, а не о его изменениях. Изменения возможны лишь в крайнем случае и при обязательном согласии заказчика.
Вот с этой точки зрения и посмотрим на проблемы, изложенные в письме.
1. Низкая квалификация заказчика. Это же и есть основание для заказа! Если бы у заказчика была высокая квалификация, зачем бы ему понадобился заказ? Впрочем, заказчик где-то должен заработать те деньги, которыми он оплатит заказ разработчикам, и именно в той области он и должен обладать квалификацией. В конце концов, разделения труда еще никто не отменял.
2. Низкая востребованность технологических решений. Мне уже приходилось писать о том, что, заставляя потребителя говорить в своих терминах, мы, в сущности, его обманываем. Конечно, есть любители новых технологий и грех не взять с них деньги за эту любовь. Но массовым заказчиком является тот, у кого есть потребность в решении собственной проблемы, а не в использовании той или иной технологической новинки. Соответственно и предлагать заказчику решение нужно, указав требуемые ресурсы (деньги, количество и качество оборудования, место для его размещения, персонал и т. д.), а не конкретные технологии. Если же вы уговариваете заказчика использовать Back Office, который обойдется ему дорого, а понять, зачем он ему нужен, заказчик не в состоянии, то это - проблема вашей квалификации, а не заказчика и не Back Office.
3. Хронический недостаток аналитиков и проектировщиков. Как может существовать фирма, занимающаяся заказным ПО, если в ней нет квалифицированных аналитиков и проектировщиков? Что она делает? Где берет деньги? Комментарии здесь, думаю, не нужны.
4. Увеличение затрат на повышение квалификации разработчиков. Это что - жалоба руководителя коллектива на своих сотрудников, жалоба посредника на тех, кого он представляет, или жалоба на себя? По мне, так, если нечем торговать, не торгуй! А чем выше качество, тем выше цена. Повышая свою квалификацию, разработчики увеличивают свою цену и расширяют круг задач, которые могут эффективно решать. Кому же, как не самим разработчикам, платить за повышение собственной квалификации деньгами и временем. Все это окупится сторицей при работе над более сложными заказами.
5. Ошибочный выбор платформы разработки - типичный случай недостаточной квалификации. Я, кстати, не согласен с тем, что Borland - плохая платформа: наша фирма (“ДИСКо”) стоит на ней. Но мы воспользовались тем, что фирма Borland опубликовала тексты OWL, и исправили в них немало ошибок. Кроме того, некоторые места мы изменили на свой вкус и используем библиотеку в таком виде. Другое дело, что между OWL и нашими приложениями стоит наша собственная библиотека. Такая структура приводит к минимальным затратам при переходе с одной платформы на другую (нам приходилось прилаживать свои библиотеки к Маку). Выбор платформы - так же свидетельствует о квалификации, как и многое другое.
6. Недостаток информации о разработках. Тут видно, откуда ноги растут. Кто же будет продавать инструментарий? Если у меня хороший инструментарий, я буду сам искать под него заказы и таким образом заработаю гораздо больше денег, чем от продажи десятка его копий. Вот если бы речь шла об информации о разработчиках, я был бы двумя руками “за”. Поскольку главным способом повышения эффективности совместных разработок является не закупка (а потом и освоение) чужого инструментария, а размещение части заказа у разработчиков, которые эту часть проекта выполнят и быстрее, и лучше (так называемый аутсорсинг). В такую игру захотят играть все. Очень нужна информация о разработчиках, но не только о том, что они умеют, а еще и о том, насколько они обязательны, сколько они стоят, как загружены, кто и сколько заплатит, если они не выполнят своих обязательств. Зачем мне изучать их инструментарий, писать на нем то, что у них давно написано, мучиться с поддержкой, когда удобнее просто распределить работу. Повторяю, разделение труда еще не отменено.
7. Программисты - народ неуправляемый. Опять непонятно, на кого жалоба. Есть программисты и программисты. Те, которые обязательны, и стоят соответственно. Время дешевой квалифицированной рабочей силы кончилось года три назад (смотри последний пункт).
8. “Вычитание стоимости”. Какое вам дело, чего хочет заказчик? Если он заказывает вам работу только для того, чтобы у близкого родственника было теплое местечко, это его право, пока он тратит на это свои деньги. Не вам решать, будет кто-нибудь читать представленную вами информацию или нет. Короче, если в проекте указаны дополнительные требования (к наличию документов, к созданию нового рабочего места для родственника и т. д.), то ваша обязанность их выполнить или отказаться от такого заказа. Зато ваше право учесть эти дополнительные требования в общей стоимости заказа.
9. Процесс пополнения знаний приостанавливается на время выполнения. Нормальный заказ (выгодный разработчику) выполняется на 80% за счет старого багажа, 10% - требует учета специфики заказчика, а еще 10% - это освоение чего-то нового, которому приходится учиться по ходу работы. Поэтому багаж хорошей фирмы (не только материальный) растет с каждым выполненным заказом. Это и есть нормальный путь развития фирмы-разработчика.
10. Про пиццу. Тут моего понимания не хватило, наверное, потому, что из дешевой и несъедобной еды я предпочитаю котлеты. Жертвовать надо не друзьями, а амбициями. Не надо садиться в чужие сани. Автор письма представляется мне человеком, никогда серьезных проектов не делавшим, но решившим продавать чужой труд, труд заказных программистов. Сегодня это требует высокой квалификации. Блаженные времена пятилетней давности, когда для разработки предлагались коллективы из нескольких тысяч программистов, слава Богу, канули в вечность. Сегодня программисты знают себе цену. Другое дело, что люди, умеющие эффективно управлять программистами (а это - не аналитика или проектирование, а тонкая и жесткая работа с творческими людьми), в большом дефиците.
И все же я благодарен автору письма за то, что он поднял проблему, существенную для сегодняшнего российского рынка ПО, правда, программисты к ней имеют косвенное отношение. Проектируемые системы стали очень сложными и разрабатывать их силами одного коллектива, даже большого, очень трудно. Здесь уместна аналогия с современным индустриальным строительством, в основе которого - совокупный труд многих организаций. К сожалению, аутсорсинг как метод решения этой проблемы хотя и привлекателен, но имеет свои недостатки, типичные для российского рынка в целом. Главное - это низкая ответственность исполнителя за исполнение (а чаще за неисполнение) своих обязательств и проблема отсутствия информации о доступных для заказов коллективов разработчиков.
Несколько лет назад я хотел создать такой информационный центр, но понял, что для его организации требуются существенные ресурсы, (например, на страховку контрактов на заказ ПО). Для обманутого заказчика или исполнителя естественно предъявлять претензии к посреднику, если не юридически, то морально. (Мы все обижаемся на телевидение за рекламу пирамид.) Вопросы гарантий выполнения взаимных обязательств при неустоявшемся рынке (я уж не говорю о кризисе) становятся самыми существенными. Поэтому такой информационный центр должен по совместительству стать страховой компанией, получая за это существенный процент от контрактной стоимости, но зато и возмещая убытки при нарушении обязательств одной из сторон.
Следовательно, начальный капитал такого центра должен быть достаточно крупным, что и остановило меня в свое время. Альтернативой могли бы стать аналитические агентства, осуществляющие продажу информации о потенциальных партнерах по аутсорсингу, но сегодня эти агентства ориентированы на другие задачи. Для получения информации о разработчиках надо скрупулезно анализировать результаты каждой сделки, что очень сложно и технически, и психологически. Да и делиться такими данными никто не торопится.
Мне, с одной стороны, приходилось слышать, что крупные фирмы по разработке ПО ведут свои базы данных по аутсорсингу, а с другой, - что в одной Москве существует порядка ста “подножных” групп и одиночек, работающих по прямым заказам из США. Мне кажется, что это свидетельствует об актуальности проблемы. К тому же в сегодняшних условиях кризиса разработка заказного ПО, не требующая ресурсов и не заметная для рэкетиров всех мастей, могла бы оказаться хорошим бизнесом при условии его правильной организации.
К Михаилу Донскому, президенту фирмы “ДИСКо”, можно обратиться по адресу: donskoy@kaissa.msk.su.
