Четвертая встреча. Тезисы

Немного запоздало публикуем тезисы 4ой встречи профсоюза.

Андрей Чернов провел разбор кейса «обсуждение нового проекта с потенциальным заказчиком». Было чрезвычайно интересно. Андрей, респект! Лично меня кейс заставил еще раз вспомнить о разнообразии возможных проектов, и заказчиков; а в процессе обсуждения -- узнать несколько интересных методов взаимодействия с заказчиком и fast-tracking-а.

Итак, собственно тезисы:.

Участвовали: Андрей Чернов, Александр Сергеев, Николай Иванович Глумов, Костя Иванов, Денис Пушкин, Александр Калугин, Андрей Кузнецов, Лена Тимбай, Костя Быченков (заочно).

Внимание: Совпадение имен и названий с реальными случайно – и суть лишь попытка упростить разбор кейса в ограниченных рамках встречи профсоюза. 

Часть первая: Первая встреча с заказчиком.

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

Дополнения:
1. Заказчику «явно» ничего не надо, но «про себя» он знает, что может быть улучшено в его организации с использованием дополнительной автоматзации – то есть потребность у него всё же есть.
2. За рамками кейса остаются организационно-юридические вопросы взаимодействия с компанией. Концентрируемся на технических аспектах проекта.

<Андрей исполняет роли представителей заказчика (ген директора, тех директора и т. д.), участники профсоюза – представляют интересы компании разработчика. В результате встречи, разработчикам удалось получить доступ к некоторым руководящим документам и технической документации СВГК. Заказчик рассказал немного о процессе доставки газа потребителям, осуществляемым компанией. Разработчики уцепились за частный аспект этого процесса (ввод схем и паспортов) и выяснили доп. информацию по этому аспекту. Получив эту информацию, разработчики пошли думать над ком. предложением.>

После того как «первая встреча с заказчиком» состоялась, был проведен разбор замеченных промахов незадачливых разработчиков:

Результаты обсуждения:

1. Во время первой встречи необходимо как минимум продемонстрировать свою компетентность как разработчика и обнаружить проблемы, которые есть у заказчика. Если есть реальный опыт у разработчика в аналогичных проектах – основной целью встречи – должно быть демонстрация этого опыта заказчику.

2. Разработчику не стоит «угадывать» проблемы заказчика, или говорить что вы знаете о проблемах, о которых он сам не сказал.

3. Лучше на первую встречу к заказчику разработчикам идти не своим небритым коллективом, но брать с собой барышню… Если разговор заходит о деньгах – присутствие барышни не даст заказчику прямо сказать – «денег у меня щас нет…» :)

4. Заказчик, даже если цель встречи не достигнута – всё равно присматривается к различным подрядчикам. И хотя бы «себя показать» -- уже не плохо…

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

6. Если есть такая возможность – разработчику стоит предварительно выяснить хоть какую-либо информацию о компании, и что могло бы быть ее директору наиболее интересно.

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

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

9. Целесообразным первым этапом выполнения проекта будет – проведение предварительного обследования предприятия (за счет разработчика) с целью выявления основных функциональных подразделений и взаимодействий между ними, объектов учета. В качестве следующего шага – проведение полного обследования предприятия уже за счет заказчика. С целью разработки системы управления предприятием.

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

11. Выбирая представителей заказчика, с которых разработчику хотелось бы пообщаться необходимо помнить о их личных интересах в ваше проекте: явных или подспудных – в общении с разработчиком.

Часть вторая. Вторая встреча с заказчиком

Вводная: В результате первой встречи договорились, что разработчики за свой счет проводят предварительное обследование предприятия. Разработчики это обследование провели, и выявили доминантный процесс, какие подразделения компании заказчика в нем участвуют. В рамках второй встречи разработчикам необходимо выяснить приоритетный участок для автоматизации и попытаться раскрутить заказчика на след этап: либо на детальное обследование всего предприятия, либо какого-либо подразделения/фрагмента доминантного процесса, разработка АИС для этого участка.

Дополнение: Целесообразным является попытка в качестве следующего этапа рассматривать разработку некоторой системы учета (так как это базовый элемент любой системы управления предприятием).

<Андрей продолжает играть всех со стороны заказчика. Разработчики предоставляют схему выявленных бизнес-процессов и пытаются заговорить о том, что необходимо детальное обследование какого-то участка – приоритетного центра приложения силы. Разговор постепенно сводится к участку обработки сигналов об авариях. Выяснили, что СВГК -- не успевает устранять аварию за нормативные 24 часа. Не всегда есть возможность эффективно контролировать работу подрядчиков, которые проводят работы по устранению аварии. Разработчики попытались свести следующий этап к реализации системы по автоматизации процесса устранения аварии. Заказчик высказал опасение, что ему необходимо понимать весь контекст, и что ему не хочется автоматизировать полностью аварии. В итоге сошлись на том, что в качестве следующего этапа следует рассматривать обследование средней глубины сложности всего предприятия (за счет заказчика) и разработку АИС «Устранение аварий»>

Тезисы обсуждения:

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

2. Перспективным моментом представляется все же получение контракта на кусок – как метода снижения недоверия между заказчиком и исполнителем, способа исполнителю проявить себя.

3. Нельзя забывать про этапы информационного наполнения автоматизированных систем учета. Даже если разработка системы возможна «в целом», возможно стоит дробить этап разработки на несколько под-этапов , подразумевая поэтапное наполнение и внедрение системы в различных подразделениях заказчика.

4. Задачи, не связанные с массированным вводом данных, дают наиболее очевидный кратковременный эффект от внедрения, однако основу системы учета на предприятии составляет именно система ввода первичных данных – объектов учета. Это именно тот фундамент, без которого дальнейшее развитие системы – будет сложным.

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

6. Несмотря на то, что этапы анализа – разработки ТЗ и непосредственно кодирования – это разные этапы, делать эти этапы последовательно – вызывает дисбаланс загрузки различных специалистов в компании- разработчике. По возможности, есть смысл параллелить этапы разработки ТЗ и непосредственно кодирования по крайней мере частично – чтобы этот дисбаланс компенсировать.

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

Использование количества функциональных единиц – согласованное с внутренними регламентами предприятия – хорошая метрика, которая позволяет заказчику сопоставить трудоемкость задач с реалиями своей организации.

8. Даже результатом фазы обследования / выявления требований не должен быть просто документ. Так как это не очень хорошо с точки зрения заказчика. Хорошим кандидатом на параллельную задачу, которая будет давать реальное value для заказчика, является задача учета – ввода данных об объектах учета в систему. Эта задача не очень сильно зависит от результатов фазы анализа – с другой стороны – ее результаты легко осязаемы. Например можно создавать печатные копии документов с сущностей, введенных в БД.

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

10. ТЭО – Может ли компания-разработчик дать ТЭО в результате фазы анализа? Вообще говоря, если объектом фазы анализа является именно обследование предприятия. Если заданы некоторые метрики/цели (например, среднее время выполнения какого-либо технологического либо бизнес-процесса), которые прямо или косвенно конвертируются в деньги – ТЭО сформулировать можно. При разработке системы учета, хорошим кандидатом в ТЭО является сокращение потерь, связанных с невозможностью контроля над выполнением работ подрядчиками, или внутренними подразделениями. Даже если мы не сможем количественно оценить НА сколько изменятся эти потери. Мы можем сказать, что после внедрения системы, эти потери будут составлять НЕ БОЛЕЕ ЧЕМ.

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

Размышления в конце.

1. Как быть если заказчику действительно ничего не нужно?
Одним из вариантов является попытка эти желания заказчика создать/сгенерировать: через то, что есть в аналогичных организациях, используя потребности в PR (например, начать с разработки сайтика). Если вы общаетесь с техническим директором (представитель заказчика), которого дергают по каждому поводу – то его мотивами могут быть сокращение количества таких нештатных ситуаций.

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

Еще одной альтернативой является создание системы контроля исполнительской деятельности.

2. С точки зрения устройства системы управления предприятием – необъодимо помнить что существует два подхода: слабый или сильный. Слабый – просто некоторый набор реестров, типовых документов и права доступа на их редактирование. Сильный – имитация бизнес или технологических процессов – визарды – которые ведут исполнителя по бизнес-процессу. Более сильный эффект от автоматизации дает сильная схема. Для некоторых стандартизированных процессов – сильный метод требуется нормативным актами.

Именно из создания сильной системы может следовать удовлетворение интереса технического директора: любой сигнал/распоряжение – исполняются до конца и люди не жалуются на отсутствие информации – всё в системе есть, пользуйся, бери…

3. При проектировании системы необходимо в основу брать реальные объекты предметной области и физические связи между ними. Ни в коем случае нельзя ставить в основу дизайна системы, структуры базы данных, руководящие документы – так как их очень просто поменять.

Вот и всё