Доброго всем!

У нас в компании решили составить список вопросов, которые должны выяснить продавцы на стадии предпроекта.
Нужно теперь продумать, что аналитику важно знать в момент старта проекта, чтобы максимально хорошо начать работать
 
Я пока смогла набросать такой список:
1. Документы, которые регламентируют работу заказчика (внутренние, внешние, возможно законодательные), в идеале сами документы, или хотя бы их перечень
2. Требования заказчика к процессу разработки и взаимодействию с исполнителем (возможно, заказчик предпочитает определенные методологии)
3. Требования к документации (объем, соответствие ГОСТам, другим стандартам)
4. Уровень технического оснащения
5. Уровень технической грамотности пользователей (возможно, средний возраст)
6. Существующий уровень автоматизации
7. Перечень заинтересованных лиц

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

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

Ириш, посмотри в записях семинаров, в прошлом году в рамках семинаров uml2.ru мы говорили о пресейле и аналитиках.

Как показывает опыт:
1. пока не стартанет проектное обследование максимум что вам дадут - нормативную базу (на получение внутренних регламентов надеяться не стоит)
2. а вы это не прописываете в договоре (уставе проекта)?
3. см. 2
4. не дадут, могут высказать пожелания к техническому обеспечению если внедряете программно-аппаратный комплекс, могут не высказать до стадии проектного обследования
5. не дадут
6. см. 4
7. а вот тут вопрос сложный. на предпроекте скорее всего не дадут, этот список должен получить ПМ перед тем как запускать обследование

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

Да, список вопросов в анкете должен соответствовать тому. что вы хотите знать о Заказчике после проектного обследования.

Т.к. продавец общается первую очередь с тем, кто заказывает Систему, то хорошо бы узнать:
1. Какие проблемы Заказчик хочет решить с помощью ИС?
2. Какие бизнес цели преследует и каковы его потребности?
4. Какие бенефиты он хочет получить от внедрения ИС?
5. + мне понравилась анкета по интеграционным проектам, про которую говорила Ира на семинаре про присейл. Хотя возможно это уже след. стадия.

2 ichy:
IMHO Вы идете принципиально неправильным путем, техническим что ли. Таким путем Вы скорее всего и сами измотаетесь и других людей издергаете бесполезными на этой стадии требованиями.
 
Sales должен выявить ПРОБЛЕМУ(-ы) заказчика и предложить решение. Поищите-почитайте про SPIN.
Далее появляется формулировка (обычно очень краткая) задачи в целом, и уже потом возникает потребность в информации о компании заказчика. И вот тут уже перед исполнителем встает ряд вопросов, на которые и должно ответить обследование. На этой стадии и нужно правильно определить его цели, сформулировать те самые вопросы, на которые в любом случае нужно получить ответы. А для этого и нужны некоторые (или все) те самые пункты, которые Вы пишете. Но определить что именно нужно, каким образом следует получать нужную информацию и от кого - это и есть задача аналитика.

А то, что Вы написали - "взгляд изнутри, со стороны аналитика" практически бесполезен для результата. Ведь он ориентирован на то, "чтобы аналитику было легче/проще выполнить свою работу качественно". Само стремление к качественному результату похвально, но настоящий правильный результат - клиент удовлетворенный внедренным решением. Поэтому, смею Вас заверить, в проектах нет отдельно взятой работы, будь то работа аналитика, менеджера или разработчика. "Все работы хороши", и все должны быть сделаны качественно для получения действительно полезного для заказчика результата.

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

Спасибо, большое, я знала, что здесь мне быстро мозги в нужную сторону поставят ))
Ириш, веришь, создала тему и сразу подумала, что нужно было перед тем как писать еще раз твой доклад про пресейл пересмотреть (может, и писать не понадобилось)
В любом случае, огромное всем спасибо, теперь буду думать немножко в другую сторону

Меня иногда проще спросить чем пересматривать. Я еще пока не опытный оратор. :-(

очень понравился п5 Про техническую грамотность и средний возраст!!!!
Так недалеко до половой принадлежности и  сексуальной ориентации дойти!

Согласен с коллегами.
Основная задача продовца на данном этапе - понять, почему заказчик купил проект и донести эту мысль до "своих". Т.е. рассказать про мотивацию человека (людей), согласовавшего, утвердившего и подписавшего контракт.

очень понравился п5 Про техническую грамотность и средний возраст!!!!
Так недалеко до половой принадлежности и  сексуальной ориентации дойти!

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

Просто это не самое главное на начальном этапе проекта?

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

2kris
А что в Вашей практике узнавали продавцы на этом этапе? И как это лучше организовать, чтобы таки сработало?

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

Кстати, то, о чем писал Водолей (спасибо Вам большое) - SPIN. Много информации я пока не нашла, но то, что нашла, мне очень понравилось - это 4 типа вопросов, которые нужно задавать менеджеру по продажам. Думаю, если на их основе поразмыслить, можно придумать что-то хорошее

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

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

P.S. по SPIN смотрите книжку Нила Рекхема (Neil Rackham) Продажи по методу SPIN. она есть в сети