Comments 4
Эти бы посты, да руководству заказчика. Сколько бы времени (денег) сэкономили. 1-5 заказчики вроде и понимают, но все равно пытаются экономить не на том. А п6, это действительно самый экономный способ. Но как говорит доктор Комаровский, каждый хочет получить таблеточку и решить проблемы. Сам являюсь фрилансером по поддержке одной отечественной ERP. Т.к.работаю в лучшем случае со средним бизнесом, получается общаться прямо с заказчиком/собственником бизнеса. В итоге пришел к определенным «правилам», которые быстрее налаживают диалог:
1. ТЗ
1.1. Заказчик не может составить грамотное ТЗ;
1.2. Я не могу составить ТЗ т.к. лицо заинтересованное, и не в курсе процессов заказчика;
1.3. Предлагаю идти, или наем(организация собственными силами) составителя ТЗ, либо исходить из Требований;
99,99% Заказчиков выбирают Требования, это убирает (экономит)
а) блок создания ТЗ;
б) блок согласования ТЗ;
в) блок взаимных претензий о соответствии ТЗ к результату;
г) возможно менять решения на ходу;
2. Требования, Здесь стратегия одна
2.1. Выявить задачу
2.2. Определить как она решается сейчас и построить схему;
2.3. Отразить схему на готовом решении или адаптировать готовое решение;
тут я веду себя как «д… новичек», с заказчиком проговаривается, кто что делает (определяю схему), проверяется логичность каждого этапа (вдруг его можно выкинуть или упростить), и к концу разговора у заказчика появляется схема, которую он полностью понимает (с учетом особенностей, которые иногда опускают), а я получаю фактически упрощенное ТЗ
3. Интерфейс — правило 1, каждое решение пишется в 3 этапа
3.1. Каркас (на основе разговора с заказчиком) который выполняет основные функции (тут заказчик получает что-то для визуального понимания решения)
3.2. Изменение каркаса, до уровня — выполняет все задачи (часто у заказчика, после 3.1, появляется много новых идей, т.к. он уже видит как это будет, иногда с переделкой каркаса, но заказчик уже прямо говорит что хочет )
3.3.«Визуализация» раскраска, расстановка (некоторые заказчики это делают сами, чем экономят свои деньги)
4. Тестирование — Только средствами заказчика
4.1. Мне (как тому козлу в огороде) трудно проверить свой код
а) я знаю ку да нужно и не нужно клацать;
б) я работаю на тестовых данных;
4.2. Заказчик сразу видит
а) технические ошибки;
б) ошибки процесса, и может изменить задачу;
Вроде все.
1. ТЗ
1.1. Заказчик не может составить грамотное ТЗ;
1.2. Я не могу составить ТЗ т.к. лицо заинтересованное, и не в курсе процессов заказчика;
1.3. Предлагаю идти, или наем(организация собственными силами) составителя ТЗ, либо исходить из Требований;
99,99% Заказчиков выбирают Требования, это убирает (экономит)
а) блок создания ТЗ;
б) блок согласования ТЗ;
в) блок взаимных претензий о соответствии ТЗ к результату;
г) возможно менять решения на ходу;
2. Требования, Здесь стратегия одна
2.1. Выявить задачу
2.2. Определить как она решается сейчас и построить схему;
2.3. Отразить схему на готовом решении или адаптировать готовое решение;
тут я веду себя как «д… новичек», с заказчиком проговаривается, кто что делает (определяю схему), проверяется логичность каждого этапа (вдруг его можно выкинуть или упростить), и к концу разговора у заказчика появляется схема, которую он полностью понимает (с учетом особенностей, которые иногда опускают), а я получаю фактически упрощенное ТЗ
3. Интерфейс — правило 1, каждое решение пишется в 3 этапа
3.1. Каркас (на основе разговора с заказчиком) который выполняет основные функции (тут заказчик получает что-то для визуального понимания решения)
3.2. Изменение каркаса, до уровня — выполняет все задачи (часто у заказчика, после 3.1, появляется много новых идей, т.к. он уже видит как это будет, иногда с переделкой каркаса, но заказчик уже прямо говорит что хочет )
3.3.«Визуализация» раскраска, расстановка (некоторые заказчики это делают сами, чем экономят свои деньги)
4. Тестирование — Только средствами заказчика
4.1. Мне (как тому козлу в огороде) трудно проверить свой код
а) я знаю ку да нужно и не нужно клацать;
б) я работаю на тестовых данных;
4.2. Заказчик сразу видит
а) технические ошибки;
б) ошибки процесса, и может изменить задачу;
Вроде все.
Спасибо за статью. Весьма жизненно и по делу.
3-й пункт — лотерея. Кажущееся хорошим в процессе выбора решение может содержать кучу неисправимых несоответствий реальным требованиям, которые выяснятся только в процессе проекта.
4-й пункт — вопрос очень сложный. Часто бывает, что заказчик, «обладающий соответствующим опытом» — это катастрофа для проекта в целом. Такие люди часто жестко прессуют, внедренцы вынуждены «подвинуться», но при этом, понимая, что за эти сроки/деньги ничего хорошего невозможно сделать, делают всё очень формально, что не может удовлетворить бизнес. Тут конечно, очень сильно зависит от действий обоих сторон, но при таком развитии ситуации совместная работа прекращается, и стороны начинают думать, как бы друг друга обхитрить. Ничего хорошего из этого не выходит, конечно.
4-й пункт — вопрос очень сложный. Часто бывает, что заказчик, «обладающий соответствующим опытом» — это катастрофа для проекта в целом. Такие люди часто жестко прессуют, внедренцы вынуждены «подвинуться», но при этом, понимая, что за эти сроки/деньги ничего хорошего невозможно сделать, делают всё очень формально, что не может удовлетворить бизнес. Тут конечно, очень сильно зависит от действий обоих сторон, но при таком развитии ситуации совместная работа прекращается, и стороны начинают думать, как бы друг друга обхитрить. Ничего хорошего из этого не выходит, конечно.
3-й пункт самый реальный, просто нужно не полениться и тщательно опробовать его на реальных данных и ситуациях.
4-й пункт — это проверка внедренца на вшивость. Большинство внедрителей заинтересовано тупо продать как можно больше софта, кое-как его запустить и добиться подписания акта сдачи в эксплуатацию, невзирая на недоработки и нестыковки. Очень важно не закрывать глаза на эти недочеты, а требовать исправления или скидок, ибо потом придется устранять чужие недочеты за свой счет.
4-й пункт — это проверка внедренца на вшивость. Большинство внедрителей заинтересовано тупо продать как можно больше софта, кое-как его запустить и добиться подписания акта сдачи в эксплуатацию, невзирая на недоработки и нестыковки. Очень важно не закрывать глаза на эти недочеты, а требовать исправления или скидок, ибо потом придется устранять чужие недочеты за свой счет.
Sign up to leave a comment.
Можно ли снизить стоимость внедрения ERP-системы?