Как работать с клиентами и сдавать проекты

* Как работать с заказчиками?

Многие клиенты сами хотят, чтобы решили их проблемы. Только обычно за минимальные деньги. И чтобы самим не участвовать.

В общем, принцип простой: «Дай мне кнопку, чтобы нажал, и всё стало хорошо»

Попытки убедить и дать документацию (хотя бы на нескольких страницах) - приводило к недоумениям и часто клиенты делегировали это мне.

Приходилось работать с непосредственными пользователями системы и поправлять её, пока она не будет удовлетворять этому финальному клиенту. Потому что самим начальникам нужно, чтобы решилась проблема - детали их не интересуют.

История 1:

В начале моей карьеры был случай - надо было написать документооборот. И тех. задание пришло на одной странице - мол сделай мне чтобы документы ходили вот такие по маршруту.

Написал за месяц и поехали ставить. А на месте оказался эксперт по документообороту и он внёс правки.

Так повторялось 9 раз, пока программа не разрослась до 42к строк кода и не стала достаточным документооборотом.

Но при внедрении оказалось, что у мерии много филиалов - и их тоже надо было обслуживать. Это были времена, когда 32кбит было хорошей скоростью и стабильность передачи не радовала. Пришлось написать дозагрузчик файлов - чтобы их можно было докачивать даже после разрыва соединения. И сериализовывать документы чтобы система с той стороны тоже понимала, что пришёл документ.

Опыт показал - что работы в 3 раза больше, чем думаешь ты (заказчик даже не предполагает объёмы).

И без чёткого тех. задания - будешь двигаться итеративно, часто возвращаясь и начиная заново некоторые участки работы.

Но, если ты начнёшь напрягать заказчика чётким тех. заданием - он часто уходит. По его разумению - ты перекладываешь свою работу на него.

* Как убедить, что новые правки будут дорого стоить или долго делаться?

Часто заказчик постоянно вносит правки. И хорошо, когда вы сидите на подписке - и тогда пусть правит хоть до посинения. Но некоторые хотят за фиксированную сумму править так же, как будто платят постоянно.

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

Или же заказчик начнёт отнекиваться и уходить (иногда насовсем).

Вообще - работа с правками - болезненная тема, потому что мы с разных сторон смотрим на проект. Заказчику надо, чтобы было быстро и дешёво, но при этом решало его проблему (которую он начинает формализовывать только когда увидит рабочую программу), а с нашей стороны - получить достойную оплату за проделанную работу.

История 2:

Делал как-то проект для управления временем мастеров ремонтников машин. Тех. задание было на одном листе их пяти пунктов. Это меня насторожило, но рекомендовавший их человек заслуживал доверия. Поэтому начал работать над проектом.

Когда через пару месяцев и много правок написал все требования - получилось 10 листов функций в проекте.

И тут меня посетила идея - запросить у клиента денег за правки. Предоплата уже окупилась, и надо было получать ещё транш. Составил требование и описал, что надо сделать и сколько будет стоить.

Но как результат - клиент заморозился и проект забросили. И это было неприятно - столько времени потрачено, а пользы людям не приносит.

* Как сдавать проекты?

Сдача проекта часто состоит из нескольких этапов.

На первых ты для высшего руководства показываешь красиво. А потом начинается этап передачи конкретным пользователям. И тут уже начинаются проблемы.

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

История 3:

Создавал мнемосхему города для телеком-корпорации. Получал данные со станций S12 - парся её отчёты. И отображал на мнемосхеме (плюс было создание отчётов и запрос к станции выполнить команду).

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

И всё проходило успешно, но тут директор просто позвонил на дальнюю станцию, чтобы убедиться что нет проблем. И как оказалось - именно этот тип отчёта глючил и не показался на мнемосхеме.

Пришлось извиняться и править позже.

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

И к каждому надо было найти свой подход - у каждого было своё мировоззрение.

И параллельно при этом менять программу, отлаживая ошибки и работая с клиентами внутри корпорации.

Плюс - обучение специалистов.

Поэтому - стоит планировать внедрение/сдачу проекта как длительную последовательность действий. И хорошо бы, чтобы она оплачивалась. Многие про это забывают.