Глава 3 Советы программисту
Пошаговая стратегия работы с клиентом
Вот стандартная схема продаж 1С-услуг:
1. Провести предпроектное обследование.
2. Написать техническое задание на внедрение программы.
3. Внедрить программу.
4. Заключить договор обслуживания.
Каждый из этапов оплачивается отдельно. Согласно этой стратегии заказчик видит результаты работы программиста (и может реально вмешаться в ход внедрения) только на третьем этапе. Вы можете возразить, что клиент сам формулирует и пишет техническое задание. На это я возражу так: техническое задание пишется группой программистов для себя же, а у заказчика просто нет людей, которые бы обладали квалификацией, достаточной для составления технического задания.
Возникает противоречие. С одной стороны, разработчик должен начать строительство программы в соответствии с планом, а с другой стороны, заказчик может повлиять на ситуацию только после*того, как сможет «пощупать» систему своими руками. Выходом из противоречия может стать пошаговая стратегия.
В своей практике я почти не составляю технических заданий, так как их составление — это толчение воды в ступе. Разговор с исполнителем и язык графов позволяют на ходу составлять спецификацию задачи и почти сразу приступать к программированию.
Пошаговая стратегия осуществляется по следующей схеме:
1. Определяется участок предприятия, на котором можно провести внедренческий эксперимент. Это может быть филиал, или удаленный склад, или кондитерский цех, или магазин.
2. На основании полученного опыта программа внедряется на других участках.
Техническое задание при такой стратегии можно составлять устно. Большее
значение следует придать поддержанию психологического контакта с заказчиком, а не правильности заключения бумаг. Вместо составления бумаг можно раз в неделю устраивать «разборы полетов» и определять очередной этап работ.
Положительные стороны пошагового подхода:
• По сравнению с традиционным подходом становится быстрее понятно, чего заказчик хочет на самом деле (потому что это не всегда совпадает с тем, что он заявляет как желаемое).
• Инкрементальный подход позволяет на ходу внедрять стандартные схемы работы.
• Инкрементальный подход позволяет избежать проблемы «Даты Ч», к которой программа должна быть внедрена.
Как описать систему, чтобы ее можно было запрограммировать?
69
Отрицательные стороны пошагового подхода:
• По сравнению с традиционным подходом пошаговый подход имеет больше неопределенности в отношениях программист — заказчик.
• Появляется больший риск наслаивания срочных проблем, которые необходимо решать здесь и сейчас.
Казалось бы, в случае, когда заключается пошаговый договор, программист рискует больше, чем когда работа ведется по традиционной схеме. Однако, начиная сотрудничество, клиент вкладывает ресурсы в покупку новой программы, тратится на обучение, отрабатывает ошибки. В определенный момент времени он становится зависим от команды программистов, так что продолжить сотрудничество для него получается гораздо проще, чем прекратить.
Как описать систему, чтобы ее можно было запрограммировать?
Задача для программиста должна быть сформулирована в терминах программирования. К сожалению, не все понимают этот очевидный принцип. Чтобы задачу можно было запрограммировать, она должна содержать ключевые слова: константа, справочник, подчиненный справочник, документ, периодическая величина, начальный остаток, приход, расход, остаток, регистр, счет.
Пример переформулирования задачи
Первоначально задача была сформулирована клиентом так: «Требуется учитывать арендные выплаты за пользование холодильниками».
Изменим задачу, чтобы условие включало в себя ключевые слова из лексикона программиста.
Переформулируем задачу «для себя»: «Требуется создать отчет "клиент -холодильник - время", который должен строиться на основе регистра "Аренда". Регистр должен формироваться документом "Акт передачи холодильника в пользование"».
Для проверки правильности понимания задачи перескажем задачу заказчику.
Программист: Я правильно понял Вас, что в «1С» следует сделать документ, в который оператор будет заносить данные о том, что холодильник был передан пользователю, и на основании этого документа будет начисляться помесячная аренда?
Клиент: Да, Вы правильно поняли.
Клиент подтвердил правильность рассуждений, значит можнопрограмми-ровать.
Для чего это нужно?
Просите клиента объяснить, для чего ему нужно то, о чем он просит. Обсудите, как он будет использовать плоды вашего труда. Может быть, он неверно представляет себе конечный результат? Попробуйте в уме проиграть различные варианты будущего.
Скажем, клиент просит сделать реестр накладных. Попросите объяснить, для чего он ему нужен. В ходе объяснений может оказаться, что «листочек», который он просит составить, на самом деле является планом поездки экспедитора, и вам нужно организовать работу программы так, чтобы одна накладная не попадала двум разным экспедиторам. Или может оказаться, что заказчик просил сделать не отчет, а документ, по которому бы сверялись фактические отгрузки и начислялась бы заработная плата экспедиторов.
Выяснению «для чего все это нужно» хорошо помогает подбадривающая фраза «это все я хочу, для того чтобы...». Эту фразу вы говорите от имени клиента и просите его продолжить.
«Запрещенные» и «разрешенные» вопросы в метамодели клиента
Под запрещенными и разрешенными вопросами я понимаю не те вопросы, которые человек может или не может задавать, а такие вопросы, которые не ожидаешь или не предполагаешь услышать от собеседника.
Существуют разные «запрещенные» вопросы для разных специалистов в соответствии с спецификой их работы. Например, бухгалтеров интересуют бухгалтерские счета, а работника торгового отдела интересуют неснижаемый остаток, сумма товара на складе, наценка, заработная плата агентов и просроченная задолженность клиентов. Если бухгалтер начинает рассуждать о просроченной задолженности клиента (что явно не входит в специфику его работы), нужно попросить уточнить, что он имеет в виду. И наоборот, вопрос, правильно ли списывается товар со склада, возможен в метамодели бухгалтера, но никак не в метамодели торгового работника.
А что нужно на самом деле?
Что вы ответите на вопрос клиента: «Скажите, уважаемый программист, правильно ли списывается товар со склада?» Я бы ответил так:
— Насколько я понял, Вас интересует, правильно ли списывается товар с 41-го счета? (Это своегорода проверка, понимаетлимой собеседник бухгалтерскийязык.)
— Да нет, меня не интересует бухгалтерская муть... (Собеседник говорит, что он не бухгалтер.)
— Хорошо, а зачем тогда Вам нужно знать, правильно ли списывается товар? (Дело в том, что начальная фраза может звучать только изуст бухгалтера. Не бухгалтер должен сформулировать вопрос иначе.)
— Я хочу посчитать наценку. (Ага, понятно: клиент думал об одном, а задал совершенно другой вопрос.)
— Скажите, а наценка с точностью плюс-минус лапоть устроит, или же следует определять наценку с бухгалтерской точностью? (Этот вопрос сужает варианты программнойреализации.)
— Меня устроят приблизительные цифры. Я должен знать, что наценка составляет 10 %, а не 5 или 14. (Последовательнымиуточняющими вопросами было определено, что клиенту было нужно на самом деле.)
Регистры или бухгалтерские счета?
Перед проектированием программы следует выяснить, кто главный в информационной системе предприятия. Если главный постановщик задачи — торгаш, то следует программировать «Торговлю». Если львиная часть времени будет уходить на общение с бухгалтером, то следует устанавливать «Бухгалтерию».
Вы также должны иметь в виду, что вы — не единственный в мире 1С-про-граммист, и у вас есть множество конкурентов, которые спят и видят, как подпортить вам жизнь. Оградить заказчика от встреч с конкурентами невозможно. Представьте, что один из конкурентов придет и покажет заказчику-торгашу, какие в «Торговле» бывают графики, в то время как вы предоставляете ему скучные таблицы цифр. Вполне возможно, что начальник «купится» на картинки и решит, что вы — несолидный партнер.
Возникает непреодолимый культурный барьер понимания бухгалтерии торгашом и торговли бухгалтером. Бухгалтер рано или поздно захочет увидеть оборотно-сальдовую ведомость по какому-либо счету. Убедить бухгалтера в том, что торговля — это «круто», просто невозможно. Так же как невозможно убедить его в том, что переброска документов из «Торговли» в «Бухгалтерию» — это то, о чем он мечтал всю жизнь.
В вопросе, стоит ли внедрять «Торговлю» или «Бухгалтерию», следует определить уровень бардака на предприятии. Попробуйте выяснить, насколько жесткая война идет между торговым отделом и бухгалтерией. Если война есть, то лучше внедрять обе конфигурации. В этом случае вы избежите ситуации, когда у главного бухгалтера случится инфаркт из-за того, что данные в «закрытом месяце» внезапно изменились, так как работник торгового отдела откатил дату редактирования и убрал налог с продаж в одном из расходных документов.
Если же предприятие выросло из коротких «информационных штанишек», если его руководство понимает роль дисциплины в информационных системах и если изменения задним числом для такого предприятия — нонсенс, то я бы дал совет программировать информационную систему в «Бухгалтерии». Она гибче и пластичнее, чем «Торговля», к тому же все управленческие задачи, стоящие перед «Торговлей», можно запрограммировать в «Бухгалтерии».
Выясните отличия схемы, действующей на предприятии, от стандартной
Бывает так, что бухгалтеры не знают, как они работают. Работники сменяют друг друга, и некогда данные им инструкции теряют первоначальный смысл. Часть инструкций забывается, а работа ведется как получится. Часть бухгалтеров может объяснить, что они делают и что им нужно делать, но не могут объяснить, как их работа соотносится с работой других.
Приведу в качестве примера диалог программиста и бухгалтера.
Программист: Объясните, как у вас считается себестоимость.
Бухгалтер: Не знаю. Себестоимость считает плановый отдел.
Программист: Хорошо, а не могли бы Вы объяснить, какими этапами из приведенной схемы Вы занимаетесь:
62<-43<-20<г-10<-60.
Бухгалтер: У нас не такая схема. У нас вот такая схема:
20 <— 10 (производство) <— 16 <— 10 (сырье) <— 60.
Программист: Хорошо, а что идет после счета 20?
Бухгалтер: Не знаю.
Программист: А зачем вам нужен счет 16?
Бухгалтер: Дело в том, что на складе сырья продукция хранится в виде материала, а на складе готовой продукции она хранится в литрах.
Программист: А почему вы не делаете проводки 43 <— 20 <— 10?
Бухгалтер: Я не могу делать такой проводки, потому что вся продукция у меня учитывается в литрах (!).
Вот такой получился разговор. Вы что-нибудь поняли? Я — нет.
Если вы будете слушать такого бухгалтера, то вы никогда не придете к правильному решению. Стандартная схема превращения материала в готовую продукцию говорит о том, что следует делать следующие проводки: 43 <— 20 <— 10. Эту схему и следует внедрять, если никакой другой схемы нет, даже в том случае, когда клиент не совсем представляет, как все будет выглядеть.
Предлагайте свои модели поведения. Лучше пусть будет ваша модель поведения, чем никакой. Если тот, кто может повлиять на ситуацию, ничего не может привнести полезного в вашу модель, то его следует убедить в том, что ваша модель — лучшая.
У принципа «делать, как знаю» есть и оборотная сторона. Попытка уложить факты в прокрустово ложе своих представлений может закончиться печально для проекта, поскольку вы не можете учесть все существующие факторы. Поэтому следует проверять и совершенствовать свои модели. Лучший способ совершенствовать модели — общаться с профессионалами.
Советы программисту
• Программируйте только у клиента, не берите работу домой или в офис.
• Делайте работу на одном дыхании в состоянии высшего подъема. Любая задача должна быть выполнена в этот же день, иначе она не будет выполнена никогда.
• Печатайте быстрее. Изучите навык слепой печати. Научившись быстро печатать, человек не отвлекается на клавиатуру и освобождает голову для обдумывания мыслей.
• Сводите задачи к простым. Запутанные схемы приводите к описанным заранее моделям. Предлагайте типовую схему решения проблемы. Выявляйте расхождения между типовой схемой и реальной ситуацией у клиента.
• Выявите заблуждения клиента.
• Делайте только то, что необходимо, а не то, что озвучил заказчик.
• Пользуйтесь административной властью начальников клиентов.
• Если можно не программировать — не программируйте. Старайтесь свести свое вмешательство в программу к минимуму. Если отчет можно сделать внешним, то его не стоит записывать в структуру программы.
• Используйте графы при описании задачи.
• Делайте печатные формы и формы документов и отчетов красивыми.
• Делайте результаты своей работы передаваемыми другому специалисту.
• Не посвящайте одному заказчику более четырех часов в день, иначе он начнет считать, что вы постоянный работник.
Что делать с тем, что уже сделано до вас?
Нередки случаи, когда у заказчика уже установлена одна из версий программы, которую настраивали другие программисты. Что делать? Предлагать ли клиенту свою программу или взять за основу то, что было сделано другими?
Ломать — не строить, однако в пылу разрушения не забудьте, что, во-первых, кое-что вы просто обязаны сохранить (как минимум — остатки товаров, задолженности клиентов, информацию справочников). Подумайте о том, что ваши предшественники уже решили многие проблемы и обошли многие подводные камни, с которыми вам еще только предстоит столкнуться. К старой программе пользователи привыкли, поэтому вы можете встретить сопротивление, если будете что-то существенно изменять. Другой причиной не ломать сделанное может быть то, что сопровождение программы — операция менее трудоемкая, чем ее написание «с нуля». Кроме того, поддержкой может заниматься и менее опытный специалист из вашей команды, а перестройка по плечу только профессионалу высокого уровня. Наконец, вы рискуете сделать новую систему еще хуже, чем предыдущая.
Существует еще одна причина не делать крупных реорганизаций. Реорганизации — это отвлечение серьезных сил от других проектов. Если вы ведете одновременно несколько предприятий, то вам придется работать в режиме пиковых нагрузок. Клиент, у которого идет внедрение новой программы, захочет лицезреть вас каждый день. Стоит нескольким клиентам пожелать этого одновременно — и ваша клиентская сеть затрещит по швам.
И наконец, еще один довод в пользу того, чтобы сохранить созданное другими. Заказчик, как правило, понимает термин «обслуживание» в смысле «чтобы все работало», а не в смысле «сломать то, что уже есть, и сделать по-другому, чтобы было за что выставить солидный счет», как понимает его программист.
Возможно, вы возразите, что предыдущий программист был совсем дурак и от него было больше вреда, чем пользы. Откровенно говоря, я таких случаев не встречал. У другого всегда есть чему поучиться и есть что позаимствовать.
Содержание раздела
