Письмо в редакцию
Павел Сенаторов
Загадка
Один программист и одна организация договорились, что программист напишет программу. За пять недель, за 1000 долларов.
Через полтора месяца заказчик выясняет, что программист делает меньше того, что в итоге нужно заказчику, что стороны понимали задачу по-разному. Заказчик хочет, чтобы неопределенное дополнительное количество работы было сделано за те же деньги, а программист, конечно же, хочет, чтобы ему оплатили тот труд, который уже вложен.
Знакомая ситуация? Вопросы: Что бывает в таких случаях? Почему так получилось? И извечный вопрос русской интеллигенции: Что делать? Дайте свет в конце туннеля.
Теория
Обратимся к книге по ведению программных проектов английского военного программного инженера Кулинга: Cooling. Software design of real-time systems. Я по ней учился. Главные характеристики программного продукта: стоимость, скорость разработки, функциональные возможности, надежность, сопровождаемость. Этапы ведения проекта: анализ задачи; создание эскизов проекта, различающихся по характеристикам; выбор подходящего варианта; проектирование; собственно программирование и отладка; тестирование; документирование; сопровождение.
Типичное распределение ресурсов, т. е. денег, таково. На сопровождение тратится примерно половина всех денег. Остальное делится в такой пропорции: половина уходит на анализ и проектирование, шестая часть на программирование и отладку, треть - на тестирование.
Читаешь такую книгу и глотаешь слюни. Как все умно и красиво, и как это сильно расходится с нашей реальностью.
Практика
Вернемся же к незадачливому программисту и его заказчику. Есть ли у них анализ, проектирование, сопровождение? Кто их делает, сколько ресурсов это берет?
Итак, самое начало проекта. Все начинается с заказчика. В ведении государствнной организации находятся некоторые официальные документы, и одна из задач организации - распространение (читай: продажа) этих документов. Раньше с них просто снимали ксерокопии, сейчас печатают изображения из предварительно отсканированных файлов, и, конечно, в этот момент появилась идея оформить документы на компакт-диске. Итак, организации нужна была программа для просмотра этих документов, которая защищала бы документы от копирования с компакт-диска. Это начальная постановка задачи.
Теперь вспомним западные книжки: был ли анализ, эскизы решения, выбор варианта, проектирование?.. Заказчик обсудил способы защиты с парой организаций и закупил аппаратные ключи защиты. Таким образом, с его точки зрения, анализ, эскизы и выбор варианта состоялись. Время на исполнение - пять телефонных звонков и два часовых совещания. Участники этапа - два менеджера и один администратор, мастер на все руки. Никто их них не имеет опыта защиты информации, все они не программисты, не аналитики и не программные инженеры.
Теперь на сцене появляется второй наш герой - программист. Высшее образование, выпускник физтеха. Опыт работы - больше десяти лет, за плечами десятки проектов, некоторые - настоящий hi-tech. В общем, алгоритмический успех. Довольно детально знаком с западными технологиями. Добился от своих программ высокой надежности. Скорость программирования - несколько быстрее среднего. Опыт консультирования - анализ, проектирование, разработка ключевых алгоритмов и структур данных. И вдруг: договаривается устно, без технического задания, сделать заказ за пять недель. Спросим его, какие из этапов подразумевались им в момент старта проекта как часть его работы. Оказывается, только проектирование, программирование и отладка. Где анализ и выбор варианта? Где документирование и тестирование? Сопровождение, наконец? Что это - туман в голове, затмение, головокружение?
Прошло шесть недель, т. е. больше оговоренного срока. Программа работает, и ее пора сдавать. За это время сделан и проект - неформально, но вполне прилично, поскольку сказывается опыт, да и программа довольно маленькая. Написан и отлажен почти весь код под этот проект. Очередная версия программы отправляется заказчику. Завязка пройдена мирно, а теперь - кульминация. Представитель заказчика, по своим обязанностям администратор и продвинутый пользователь, обнаруживает, что степень защиты данных гораздо ниже, чем рассчитывала его организация.
Опустим дальнейшие события - что-то среднее между драмой и перепалкой в битком набитом автобусе. Тут и страх, и недовольство, и умышленное сокрытие информации. И взаимная попытка остановить крушение надежд.
Равнение на Запад
Как делают такие проекты в США, на родине коммерческого программирования? Я почерпнул эти сведения от своих знакомых, уехавших туда работать, фактически эмигрировавших. Они работают по контрактам и занимают точно такую ту же позицию, что и наш герой-программист. В их обязанности входят переговоры с заказчиком, в какой-то мере выбор решения, проектирование, конечно, кодирование и отладка и в очень малой степени - тестирование. Анализ проводит заказчик еще до того, как обратиться к программистам. В проекте всегда участвует несколько исполнителей, так что тестирование и документирование - забота других людей.
Сравним количество рабочих дней, число участников проекта и время исполнения - как все это планируется в начале проекта, в момент договора. Время исполнения - как правило, несколько месяцев, обычно от трех до шести. Считается, что меньше трех - слишком малый срок, чтобы сделать целый проект. А больше шести месяцев - это уже вопрос бюджета. Задачу делят на этапы. Платят не за готовый продукт, а производят почасовую оплату, так что в случае неудачи заказчик оплачивает рабочее время программиста и получает недоделанную программу, а исполнитель рискует своей репутацией, но не деньгами. Конечно, бывают и заказы “под ключ”, но их берут фирмы, и стоят они в несколько раз дороже. Таким образом оплачивается риск фирмы-исполнителя с одной стороны, и сокрытие всех “потрохов” проекта, с другой. Фирма-исполнитель за такие деньги действительно “делает заказчику счастье”. И “счастье” подразумевает, что заказчик участвует в минимуме операций, фактически лишь в том, чтобы подтвердить проделанный фирмой-подрядчиком анализ задачи и на последней стадии оттестировать принимаемый продукт.
Отгадка
Как же получается, что заказчик почти ничего не знает о жизненном цикле программного продукта, его этапах и оценивает трудоемкость в несколько раз ниже реальной? И почему происходит так, что исполнитель-программист из раза в раз договаривается делать проект, игнорируя большие этапы работы, без технического задания, без малейшего намека на методичную оценку трудоемкости?
Я предлагаю искать отгадку в двух плоскостях - экономики и человеческой психологии. Если кратко, то душа требует счастья, а не денег, а экономика диктует рыночную ситуацию, которая как раз связана с деньгами, сроками и условиями.
Предположим, вы заказчик. В своей работе вы нашли некое место, которое, по вашим расчетам, может быть качественно покрыто программой. Конечно, вы как заказчик плохо знакомы с тонкостями исполнения программистских заказов. Вы спрашиваете своих знакомых бизнесменов, сколько это будет стоить и каков реальный срок. И, конечно, хотите заплатить чуть меньше и получить чуть быстрее. А поскольку ситуация “рыхлая” и найти положительный опыт среди знакомых, как правило, довольно трудно, решение о сложности и стоимости принимают конкурирующие за заказ программисты.
Теперь предположим, что вы коммерческий программист, т. е. пишете программы за деньги. Вы конкурируете со своими собратьями. Чтобы получить заказ, называемые вами цены и сроки должны быть чуть меньше, чем у ваших конкурентов-программистов. И вы оказываетесь перед странной дилеммой: взять заказ на невыгодных условиях либо уйти из ниши заказных проектов, т. е. переквалифицироваться, пойти на ставку или уехать на Запад.
Спросите у программиста, какова его профессиональная мечта? Почти наверняка реализовать свою собственную идею и распространить программу по всему миру. Это идеал, и коммерческие заказы оказываются доступным приближением к нему. Пусть вы, программист, делаете программу “на дядю”, пусть это не ваша собственность, но это ваш проект, ваши алгоритмы, ваш код и полученный вами результат, который реально используется. И в этом заключается психологический момент: для внутреннего мира человека значимость собственных проектов оказывается очень высокой, настолько высокой, что взять себе проект на любых условиях бывает более приемлемо, чем отказаться от конкуренции и сменить способ заработка. Программист как бы закрывает глаза на реальную сложность и многогранность заказного проекта, “забывает” об анализе, техническом задании, взаимопонимании с заказчиком, оценку сложности проекта, у него нет уверенности в том, что заказ будет оплачен, он забывает про документирование, тестирование и сопровождение да еще преуменьшает сложность и трудоемкость некоторых компонентов системы, оставляет их оценку “на потом” и... и берет проект, лишь бы оставаться со своей мечтой о собственных проектах и опередить другого программиста, который хочет примерно того же. А программистов много.
Заложниками этой ситуации в результате являются все участники. И заказчики, так как они не имеют реального представления о сложности и цене проекта. И программисты, поскольку с такими успехами, больше похожими на пиррову победу, им никогда не осуществить своей мечты. Становятся заложниками и те программисты и фирмы, которые умеют считать реальную трудоемкость, реальное время исполнения и цену проекта - они оказываются вне конкуренции и вне бизнеса по психологическим причинам: самообманывающиеся программисты настолько “честно” продают себя, что заказчик не может выявить подвоха. Программист действительно абсолютно верит в свои оценки и ведет себя соответственно этим оценкам.
Свет в конце туннеля
Так что же делать? Пусть каждый позаботится о себе сам. Что можно предложить менеджеру, который хочет получить программное счастье локальных масштабов? Припомним: бесплатный сыр бывает только в мышеловке. Самое дешевое известное мне решение таково: на самом старте проекта, когда сама идея о заказе программы только начинает оформляться, нужно позвать консультанта. Работа потребует недели времени, в течение которой консультант вложит десяток часов своей работы в ваш проект. Самое плохое, что может случиться в результате: если реальная цена, сложность и длительность изготовления проекта окажутся слишком высокими, от заказа придется отказаться в пользу других решений. Эти альтернативные решения скорее всего предложит вам консультант. Таким образом, затраты составят несколько сотен долларов и неделю времени, что на порядки дешевле любого мыслимого проекта. Я имею в виду реальные затраты, а не те, что подразумевают конкурирующие программисты.
Как выбрать консультанта? Стоит учесть опыт участия или наблюдения за проектами от начала до конца, аналитические способности этого человека, отсутствие корыстного интереса и изначальных пристрастий к языкам и средам программирования. Узнайте, какова его теоретическая подготовка. Возможно, стоит поискать эксперта, который уже занимается такими оценками.
Что заказать консультанту? Я бы заказывал письменный анализ задачи, эскизы вариантов решения, оценку выходных характеристик этих вариантов - трудоемкости, стоимости, времени исполнения. Даже если вы не любите читать бумажные отчеты, заказать такой материал стоит. Во-первых, консультант тоже человек и письменный анализ обяжет его тщательно продумать детали предлагаемых решений. Бумага как средство для выражения мыслей и концепций оказывается более требовательной, чем устная беседа, детали которой могут не запомниться. Во-вторых, такой письменный анализ очень важен, когда вы выбираете исполнителя. Так или иначе, это хорошее приближение к техническому заданию. Кроме того, документальный отчет можно дать на ревизию вашим техническим сотрудникам.
А теперь о программистах. Что можно пожелать программисту, который узнал себя в герое этой статьи? Самое лучшее, на мой взгляд, - открыто взглянуть правде в глаза и либо признать такую ситуацию для себя приемлемой, либо идти “на ставку”, ехать на заработки в другие страны или переквалифицироваться. Например, в консультанты. Как это делаю я.
С Павлом Сенаторовым, бизнес-консультантом, программистом, можно связаться по Е-mail: arrow@aha.ru, Internet: www.postman.ru/~arrow или по телефону: (095) 430-0706.
