Как выжить программисту-одиночке

Бизнесмены давно усвоили простую истину: «Открывая новое дело, подумай, как ты будешь его закрывать». Не хотелось бы проводить прямых аналогий, но думаю, прежде чем взяться за реализацию программного проекта, не помешает поразмыслить о последствиях.

Не знаю, как у вас, а у меня 90% заказов на написание программ - это относительно небольшие и несложные приложения, работающие с базами данных: прокат видеокассет, консолидация отчетности пунктов продажи Интернет-карт и карт мобильной связи, учет продаж пленки и печати фотографий и т. п. Меняй котлеты на газеты, газеты на кассеты, кассеты на омлеты - принцип остается тот же, без кардинальных переделок движка и с косметическими переделками интерфейса. Достаточно решить такую задачу один раз (конечно, решить правильно и красиво), и потом это решение будет давать пусть скромный, но постоянный доход. Одним словом, если рука набита, то создание очередной подобной программы хоть и не принесет морального удовлетворения, зато и напряжет не сильно.

К счастью, не одной рутиной жив программист; иногда встречаются задачи рангом повыше, посложнее и поинтереснее. Но тут-то и подстерегают настоящие трудности. Давайте проиграем типичную ситуацию (автор позволил себе изложить свой печальный опыт и опыт некоторых коллег-программистов, причем многие детали совпали почти буквально).

Итак, на горизонте «нарисовался» солидный заказчик. Он готов платить хорошие (действительно хорошие по сравнению с доходами от рутины) деньги. Правда, есть два «но». Первое: заказчику нужна программа «уже месяц назад» (оттого он и готов раскошелиться, что его приперло). Второе: заказчик не представляет себе реальный срок выполнения проекта.

Ситуация для вас как разработчика очевидно перекликается со словами поговорки «И хочется, и можется, да мама не велит». Умом вы понимаете, что срок исполнения, выдвигаемый заказчиком, относится к области фантастики: ну нельзя за неделю сделать то, что требует не меньше трех месяцев упорной работы. Но как же вас достали все эти халтурные поделки… а вы ведь способны на большее и, разумеется, достойны большего вознаграждения за свой труд! Остаток дня и ночь проходят в сомнениях, а наутро вы беретесь за работу. Слабым утешением может служить лишь то, что вместо одной недели вы выторговываете себе «целых» три.

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

Вы тихим и незлобным словом поминаете родственников заказчика, его самого и себя любимого. Жадность и самонадеянность сгубила вас, и вы со стыдом признаетесь, что не можете выполнить проект. По большому счету, вы не виноваты: никто не сумел бы в эти сроки и такими силами сделать ту же работу, но теперь это не имеет никакого значения. Вы потеряли не только деньги (это дело наживное), но гораздо большее - уверенность в себе и репутацию в глазах заказчика. Неважно, что он не разбирается в специфике вашей работы. Именно потому, что он не специалист, он к вам и обратился. Важно, чтобы вы - именно вы - разбирались в специфике своей работы. А вы этого сделать не сумели.

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

Правило 1: детали решают все

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

Далеко не всякий заказчик способен написать грамотное техническое задание. Лучше не надейтесь на это и напишите ТО вместе, в четыре руки. Вовсе не обязательно оформлять его в соответствии со стандартами, хотя вид официальной бумаги может сыграть положительную роль.

Фиксируйте всё. Чертите диаграммы, рисуйте графики, таблицы, пишите формулы, делайте пометки и обязательно проставляйте дату и время рядом с каждой новой пометкой. Постарайтесь, чтобы заказчик собственноручно вносил свои пожелания и требования. Это может здорово выручить позже, когда вы будете сдавать готовую работу. Нередки случаи, когда заказчик заявляет: «Я не это имел в виду, я же вам говорил, что надо сделать то-то и то-то». Лицезрение записей, сделанных его собственной рукой, моментально сбивает спесь. Кроме того, заказчик, обнаружив, что он в свое время упустил какие-то детали или пошел по ложному пути, гораздо легче соглашается на продление срока разработки и дополнительное финансирование. Одним словом: свои ошибки заказчик должен оплатить сам.

Постарайтесь сразу же договориться о тестировании. Встречайтесь с заказчиком хотя бы раз в две недели. Показывайте ему, чего вы достигли. Не откладывайте в долгий ящик сложные вопросы и подозрительные ситуации. Чем раньше вы спохватитесь, тем быстрее и легче все исправите.

Не выбрасывайте эти заметки даже по окончании работы. Документируйте все, над чем вы задерживались дольше получаса. Многие программы живут долго, и лишние аргументы и памятки вам не помешают. Чем больше у вас «автографов» заказчика, тем проще потом «качать права».

Правило 2: сроки определяете вы

Постарайтесь дипломатично выяснить, сколько заказчик может прожить без этой программы. Заказчики склонны драматизировать ситуацию, но практика показывает, что за исключением похорон практически нет проблем, которые не могли бы потерпеть. Ведь до встречи с вами дела как-то шли! Ни в коем случае нельзя переоценивать свои силы. Забудьте о «распальцовке» и о собственной крутизне. Трезво и по возможности объективно рассчитайте время, необходимое на выполнение работы, после чего увеличьте его на 50-100% и сообщите заказчику.

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

Как рассчитать необходимый срок? Ориентируйтесь прежде всего на свой опыт и опыт своих коллег. Оставляйте себе время на праздники, выходные, сон и - обязательно - на непредвиденные обстоятельства. Нелепо думать, будто вы с утра до вечера сможете сидеть за монитором. Кроме того, могут возникнуть (и, как правило, возникают) неожиданные затруднения и невыясненные вопросы. Наконец, нельзя три месяца заниматься одной и той же работой: обязательно нужно отвлекаться. Не позволяйте обмануть себя важностью поставленной задачи. Рассматривайте задачу как интересное и полезное упражнение, как интеллектуальный вызов самому себе и не более того. Согласен, звучит цинично, но ваше основное орудие производства - ваша голова, поэтому берегите ее.

Правило 3: правило базара

Этот вопрос еще тоньше и щекотливее, чем вопрос о времени выполнения работы. Помните: проигрывает тот, кто первым назначает цену. Если заказчик упрямится и не желает назвать сумму первым, отказывайтесь от работы вообще. Скорее всего вы или ничего не получите, или будете долго клянчить свои кровные деньги. Если заказчик попросту не знает, сколько вам заплатить, предложите ему выяснить, сколько стоит час труда, скажем, программиста «1С», но при этом подчеркните, что ваша задача сложнее, ответственнее, а стало быть, и вознаграждение должно быть более щедрым.

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

Работа сделана, но не оплачена - бывает и такое. И, увы, довольно часто. В этом случае нужна какая-то гарантия того, что вы все-таки получите деньги. В идеале нужно было бы еще до начала работы заключить договор - тогда ваше дело в суде практически на 100% выигрышное. Но такие варианты в нашей стране пока что исключение. Поэтому придется обезопаситься подручными средствами.

Главное: не оставляйте в программе закладок. Не унижайтесь до этого. Не разрушайте базы данных, не форматируйте жесткий диск заказчика. Не «подвешивайте» компьютер. Не «сливайте» в тайне от заказчика его информацию по почте. Не сговаривайтесь с его конкурентами или с вышибалами. Одним словом - никаких деструктивных действий. Самое простое - отключить некоторые функции (например, печать, сохранение в файл, экспорт в Excel и прочее). Или пусть программа автоматически по истечении какого-то времени переходит в демонстрационный режим.

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

Стоит ли вообще отключать возможность запуска программы? Не уверен. Я предпочитаю втянуть заказчика в свою игру, заставить его привыкнуть к программе. Пусть потом попробует отказаться! Главное - не переборщить. Наказание должно быть адекватным проступку.

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