Так как статья для заказчиков, а не для разработчиков, поэтому, когда говорю «Вы», имею в виду заказчика.

Начну с большущей просьбы не только к заказчикам, но и к разработчикам забыть термин «оптовый магазин». Если мы будем его употреблять, автоматически будет идти ассоциация с Интернет-магазином и сайтом. Автор статьи прав, система оптовых продаж или b2b-система — это не сайт и не «корзинка», это система автоматизации Ваших (уважаемый заказчик) процессов продаж, повышение эффективности Вашей компании, то есть бизнес-система. Поэтому у нее другая стоимость, другие сроки разработки, другие затраты времени и мозгов на Вашей стороне, и такие проекты делают не обычные сайтостроители, точно так же, как обычные ремонтники не проектируют и не стоят эстакады. Это надо усвоить обязательно, иначе так и будем продолжать не понимать, почему это стоит миллионы и делается год. Самое ужасное, что этого не понимают не только заказчики, но и многие разработчики не знают, почему нельзя быстренько на Битриксе развернуть магазин и запустить стандартный скрипт интеграции с 1С.

По пунктам статьи.

1. Очень порадовало, что пунктом первым в статье идет цель. Без ответа на вопрос «нафига» делать нельзя ничего. Многим просто на лбу себе вытатуировать: «прежде чем что-то сделать, спроси себя «зачем».

2. Второй пункт тоже очень правильный, но я бы рекомендовала его развернуть.

Нужен не просто ответственный сотрудник. Нужен двигатель, человек с драйвом. Без двигателя и драйва будет труп. В идеале двигателем должен быть тот же самый сотрудник, который изначально решил делать проект, потому что если ответственный сотрудник — назначенец, не будет драйва, не будет и толку. Если Ваш проект сильно завязан с учетной системой (особенно если у Вас не просто 1С, а SAP какой-нибудь), то профессия идеального двигателя — системный аналитик. То есть человек, который одновременно рубит и в IT-вопросах своей системы, и в бизнесе компании, в которой работает. Такой человек — редкость, за 14 лет своей истории мы таких встречали ровно четыре. И именно проекты под руководством этих людей самые успешные и живучие.

Стоит также сказать, что одного сотрудника на стороне заказчика мало. Обязательно должны быть не просто задействованы, а проникнуться идеями проекта (1) коммерческий директор (или его аналог), который будет понимать, зачем и как эта штука будет помогать работать с клиентами, будет знать реальные процессы продаж (он тоже может быть двигателем, кстати), иначе Вы сделаете проект, а отдел продаж работать с ним не будет, и (2) айтишник, отвечающий за систему управления предприятием. Если айтишники не проникнутся идеей, то когда дело дойдет до интеграций и синхронизаций, может случиться труба и даже саботаж вида «некогда этим заниматься» (тогда проект стоИт) и «мы не хотим делать импорт-экспорт данных как в ТЗ, хотим по-другому» (а разработчику все переделывать за Ваш счет).

3. Третий пункт мне показался не совсем ясным. Как можно определить бюджет проекта? Умозрительно заказчик сделать этого не может и не должен. У нас в неделю минимум три запроса приходит на b2b с бюджетом в 100 тыс. Нужно понимать, что система оптовых продаж — не сайт (это уже было выше), значит, и стоить она не может столько же. Очень часто приходится слышать что-то типа «какие два миллиона, средняя стоимость сайта 100 тыс.» То, что эта штука работает через Интернет, не значит, что она сайт, то, что там есть корзина, не значит, что это Интернет-магазин.

Нужно найти компании, которые уже делали такие системы, и выяснить у них порядок цен. Слово «порядок» здесь употребляется математически буквально — нужно знать не примерную стоимость, а число нулей, потому что до того момента, как написано ТЗ, точного бюджета не будет. Если разработчик Вам дает сумму, прочитав Ваши требования, изложенные в файлике, не работайте с ним, он не знает, что такое разработка подобного проекта. Я не согласна с автором в том, что можно получить от исполнителя гарантию, что «в случае превышения обещанной стоимости содержания системы исполнитель будет поддерживать её работоспособность за свой счет». Во-первых, никто не будет работать за свой счет. За свой счет, это как? Не платить зарплату тем программистам, которые делают Ваш проект, не платить за офис и делать все это на улице, продать квартиру и детей не кормить? Да щас! И, кстати, в нашей стране ликвиднуть юрлицо стоит 15 тыс., вот и подумайте, что разработчик выберет, будет на Вас работать бесплатно несколько месяцев или сбежит, да так, что Вы ни по каким судам с него компенсацию не получите.

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

Во-вторых, суть бизнес-систем в том, что они изменяются в процессе не только разработки, но и внедрения (внедрение — не то же самое, что эксплуатация и поддержка, это — альфа и бета-тестирование, обучение сотрудников заказчика и его клиентов, отладка и т.п.). Да, исполнитель может сказать что-то типа «мы гарантируем стоимость, но заказчик должен гарантировать, что ТЗ будет соблюдено до последней буквы». В итоге эти гарантии приведут Вас к нерабочей системе. Ни разу в нашей практике не было такого, чтобы в процессе внедрения не оказалось, что заказчик передумал, что он решил организовать по-другому какой-то процесс. Это не форс-мажор, а нормальная штатная ситуация — попробовал, понял, что хочется по-другому, надо переделать. Мы же не сайт-визитку делаем, а бизнес-инструмент. Гнуть заказчика на тему «вы подписали ТЗ, ни шагу влево» неконструктивно, ибо в итоге (уже говорила выше) получится нерабочая система. Здесь самое место применять Agile, кстати. Разработчики в последнее время любят его обсуждать в разрезе создания сайтов, что далеко не всегда нужно, а вот для b2b Agile неплох — результат более эффективен, но (и это очень важное «но») стоимость непредсказуема. Тем не менее, менять стоимость в процессе даже при отсутствии гибких итеративных методов нормально. Поговорите с компаниями, которые внедряли у себя хоть какие-то бизнес-системы, они однозначно Вам скажут, что заранее все не предугадаешь и фиксированный бюджет не заложишь. Даже в теории сферический фиксированный бюджет в вакууме может существовать, если он заранее учитывает все абсолютно риски. А как можно учесть все риски, планируя бюджет на содержание системы на годы вперед (она ведь не пару месяцев после создания у Вас проживет). Даже если Вы определите, что систему должны поддерживать два программиста (как пишет автор), то нет гарантии, что один из них не уволится, а на его место не придет такой которому надо платить на 5 тыс. рублей в месяц больше. Вот и привет фиксированному бюджету.

4. Ключевым все-таки является опыт решения подобных задач. Ну, взаимопонимание, конечно, тоже, но это общее правило не только для b2b-систем. А вот требование о наличии сотрудников, ответственных за часть работ в системе заказчика меня удивило. Если у заказчика нет собственных специалистов по собственной же системе, то такой заказчик слишком мелок, не развит и не потянет нормальный b2b-проект. Если у Вас нет даже программиста, откуда у Вас быть системному аналитику (который у нас двигатель проекта)? Не говоря уже о том, что серьезная компания никогда в жизни не пустит «сайтоделов» в свою святая святых — систему управления бизнесом, и правильно. И кстати, по нашему опыту, чаще всего система заказчика не 1С. У серьезных компаний, которые заказывают серьезные проекты, 1С вы найдете с вероятностью процентов 5-10, а если найдете, то от 1С остались рожки да ножки, остальное переписано под собственные нужды. Тут уместна аналогия с «Битриксом» (он тоже 1С). Это прекрасный лего-конструктор, но не для нестандартных сложных задач. 1С — такая же штука.

5. Не скрывать цели от исполнителя? Так как статья для заказчиков, то заказчикам совет — даже не разговаривайте с такими подрядчиками, которые из Вас клещами сами не вынут Ваши цели при первом же телефонном звонке. Не надо с ними работать :).

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

8. Насчет интервью у клиента момент довольно стрёмный. Есть много компаний, делающих г..но-сайты за 5 тыс. рублей, у которых сотни хвалебных отзывов от клиентов. Есть много компаний, которые сделали отличные проекты, и которыми недовольны заказчики. Меня всегда ставят в тупик две ситуации (обе очень частые). (1) Заказчик одновременно офигительно доволен проектом и офигительно недоволен разработчиком. Чем дольше длится проект, чем теснее отношения, тем больше может возникнуть трений. Возможно, поэтому заказчики больше довольны сайтами, сделанными за 2 дня, чем супер-системами, разработка и внедрение которых заняли 2 года. (2) Заказчики офигительно НЕдовольные разработчиком обращаются к нему снова и снова за новыми проектами.

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

9. Советоваться с исполнителем о том, «как решить ту или иную проблему в бизнесе» вопрос, скажем так, неоднозначный. Да, действительно, у большинства разработчиков, занимающихся сложными проектами, есть бизнес-аналитики, которые более квалифицированы, чем специалисты заказчика. С ними можно и полезно советоваться. Но (и это очень важное «но») если веб-разработчик за пару месяцев разобрался в Вашем собственном бизнесе лучше, чем Вы за годы, и лучше Вас может придумать, как организовать то, за что Вам платят зарплату, фактически, лучше Вас делает Вашу работу, то не пора ли Вам уволиться? Ну, или хотя бы перечисляйте разработчику свою зарплату. Я не против консультировать заказчика по бизнесу, но тогда деньги следует не только за программирование, но и за бизнес-консультации. А ведь хороший аналитик стоит дороже программиста, а то и двух, и в человеко-часах его измерять сложно, ибо спрогнозировать, сколько часов займет «думанье» над Вашими бизнес-процессами невозможно...