Спасибо за интересную статью. Мы сделали уже несколько POS систем на заказ для западного рынка. И продолжаем разрабатывать новые. Вот есть интересный вопрос.
Если терминалы работают напрямую с облаком, то по какой логике вы нумеруете заказы в случае, если у вас сеть из трех ресторанов и в каждом по 3 терминала. Нумерация сквозная или локальная по каждому ресторану? Есть ли отдельно дневной короткий номер заказа? Могли бы подробно этот момент рассказать?
Мы подстроили процесс под функционал приложения. Получается так:
1. Продавец создает карточку проекта (связанную с его клиентом или не связанную) и загружает всю имеющуюся информацию. В последствии, если появляется что-то новое, то тоже добавляет туда в виде подгруженных файлов или комментариев.
2. Технический аналитик просматривает карточку проекта, анализирует всю имеющуюся информацию и либо формирует список вопросов, либо начинает работу над технической частью проекта. При этом иногда технический аналитик проясняет все напрямую с клиентом, а иногда через менеджера продаж.
(Сразу оговорюсь, что тут я говорю про предварительную максимально точную оценку. Оценку окончательную мы даем после прототипирования, как я и писал выше.)
3. В целом, когда информации достаточно, технический аналитик создает техническую часть предложения. Имеется в виду, что он фактически последовательно заполняет поле за полем от технической части с заголовками: «в чем цель проекта», «какие основные требования», «какие возможны риски», «какие основные модули можно выделить», «подгрузите картинку с архитектурой и опишите ее» (одну или много), «выберете технологии из списка», «укажите какие виды тестирования будут применяться», «как будет осуществляться коммуникация», «укажите документацию, которая будет предоставлена с проектом» и далее непосредственно необходимо заполнить таблицу «breakdown» где указать стадии, модули, такси и саб-таски с оценкой трудозатрат и необходимую категорию специалиста (software developer, senior software developer, project manager, QA engineer и т.п.). Далее технический аналитик планирует необходимое количество людей на стадию и сроки выполнения. Переносит отдельные задачи с одной стадии на другую. Описывает конкретный результаты после сдачи каждой стадии (если их больше одной). Когда техническая часть проекта завершена, технический аналитик ставит ее в статус «complete». Фактически количество трудозатрат и сроки проекта после этого уже определены.
4. Далее начинается ответственность менеджера продаж или человека ответственного за окончательную стоимость проекта. Менеджер продаж может просматривать техническую часть, но не может ее редактировать. Он же редактирует финансовую часть. Указывает стоимость за час, скидки, налоги (если надо) и получает общий бюджет проекта. Если продаются уже созданные части, которые имеют фиксированную цену, то добавляет их. Добавляет доп. услуги в духе обучения персонала, написание обучающей документации и т.п. Получив общую стоимость, он указывает условия оплаты включая расписание оплаты и способы перечисления денег. Плюс иногда добавляет 2-3 образца портфолио и референсов клиента, и генерит предложение. Соответственно, менеджер продаж тоже указывает статус финансовой части «complete» и после этого технический аналитик уже не может ничего менять в своей оценке.
5. Ну и часто этот процесс происходит в несколько циклов. Так как в процессе переговоров клиенту приходят в голову новые идеи или он что-то сокращает, удивив цену выше возможностей. Поступают новые требования и если они существенные мы создаем новое предложения на основе созданного, а если изменения не большие, то просто корректируем созданное предложение.
На вопрос 3 я все таки уже пытался ответить. В оценке каждой задачи у нас идет отдельная задача (или несколько) на написание текстов и работу QA инженера. То есть суммарные трудозатраты по задаче включают различные виды автоматического тестирования (для разных случаев применяются разные виды) и времени тестера. Само собой когда все оценивается техническим аналитиком он держит в уме требования к надежности и скорости системы. Исходя из этого и оценивает.
Если говорить про POS то там ключевая задача состоит в обеспечении правильности расчетов чека. Там одновременно накладываются масса условий связанных с выбранным товаром, клиентом, существующими маркетинговыми компаниями и т.п. Для того чтобы этого добиться мы все подобные расчеты покрываем тестами (и клиентскую и серверную часть) и соответственно закладываем 50-100% времени на разработку тестов от времени разработки функциональности. В местах не критичных тестов пишем меньше или вообще не пишем. Но при оценке так и пишем скажем:
Task 1 — 50 man-hours
Sub task 1 — 10 man-hours
Sub task 2 — 10 man-hours
Sub task 3 — 10 man-hours
Unit tests — 15 man-hours
QA work — 5 man-hours
Раньше мы делали все это просто в excel но потом из-за частых ошибок перешли на приложение. Но принцип тот же самый.
Спасибо за комментарий.
Мы занимаемся разработкой POS систем (www.yumapos.com). Каждая система, хоть и имеет общий функционал, уникальна и требует отдельного осмысления и последующей оценки трудозатрат. Средний разброс, как я писал выше, 5000-30000 часов. Последний раз я оценил систему в 27000 часов. И вот при оценке подобной системы мы не можем начать объяснять, что для того чтобы оценить нам нужно сделать прототип. Заказчик хочет сказать что ему надо и через несколько дней получить сроки и бюджет. Мы в этом случае, конечно, каждый раз работаем с более менее понятной для нас областью. Но размер проекта все равно требует усилий по детальной оценке. Скажем в последнем проекте, который я оценивал, было 29 модулей и еще 4 отдельным мобильных приложения с поддержкой четырех платформ (web, desktop, iOS, Android). Изначально показалось (как часто бывает), что проект максимум на 10000 часов. Но когда стал считать и прояснять мелочи получилось 27000.
Вот с чем я работаю. Я рассказал, чтобы Вы понимали мою ситуацию. У каждого она все таки индивидуальная.
Теперь отвечу на Ваши вопросы:
1. Мы разбиваем проект на этапы по следующим принципам
— первый этап — прототип, второй — создание базового функционала, третий и последующие — добавление и расширение функционала. При этом после выполнения прототипа мы корректируем все планы, чтобы они соответствовали всей имеющейся информации после создания прототипа. Корректируем бюджет и сроки.
— второй принцип заключается в том, что этапы я стараюсь разбивать не больше, чем 2-3 месяца работы, чтобы процесс оплаты протекал плавно.
— третий принцип — заказчик после каждого этапа должен видеть результаты работы. Рассказ, что мы написали всю серверную часть, которую не видно, потому что нет интерфейса не работает. Заказчик всегда хочет понимать за что он платит и так как он не программист чаще всего, лучше чтобы после каждого этапа были видимые результаты работы.
— четвертый принцип — задачи нужно разбивать настолько мелко, чтобы каждую можно было выполнить в пределах 1-10 часов.
2. Если Вы имеете в виду внедрение CRM типа MS Dinamix для заказчиков, то мы этим не занимаемся. Мы делаем проекты разработки с нуля, а также проекты когда мы разрабатываем часть Point of sale системы, а часть продаем готовые модули. Но чаще всего разработки с нуля не менее 50%. Если вопрос в том, какую CRM мы используем, то это тот функционал, что есть в swproposal.com. Она там не супер функциональная. Скорее простая. В основном мы храним информацию о клиенте и трекаем статус отношений с ним. Подгружаем файлы. На каждого клиента создаем проект и предложение или несколько предложений и также отслеживаем процесс переговоров по ним. Сразу извиняюсь, если я не совсем о том. До конца вопрос Ваш не понял.
3. Обычно мы разделяем объем работы на модули (например раздел Customers, Inventory, Orders liss). Далее делим на крупные задачи в рамках модуля (Customers groups management, customer form, и т.п.) и далее уже делим на мелкие задачи и подзадачи, чтобы каждая задача была 1-10 человеко часов. Если проект подразумевает этапы, то мы распределяем полученный лист задач на разные этапы.
4. Первоначально мы занимались разработкой всего, что могли найти. Были веб социальные проекты, мессенджеры, веб приложения для автоматизации бизнес процессов, CRM и много чего еще. Тогда мы начали работу по организации процесса оценки. Ранее оценивал просто программист на основании собственного опыта и собственной тщательности. Разные программисты давали сильно разные оценки и разную детализацию проекта. Однажды мы продали проект за 3 человеко-месяца, а делали около года. Сейчас ошибки бывают, но это не катастрофические ошибки и не выходят за пределы 20%. То, что мы сделали — заставили всех, кто участвует в продажах и оценке проектов действовать по утвержденным шагам с детализированной оценкой проекта. Так чтобы все большие задачи разбивались на логично взаимосвязанные маленькие с их последующей оценкой. Это сокращает вероятность ошибки.
5. Коммуникация, конечно, возросла. Но и возрос процент полученных проектов из тех, что мы оценивали подробно.
Не буду спорить. Если предметная область новая и требуется оценить работы из этой области, всегда велик риск ошибки. При этом системный подход с разбиением всего объема задач на конкретные такси все равно является правильным и позволяет сократить ошибки в оценках. При этом мы в этом случае во время оценки делаем дополнительное исследование проблемы. Человек, ответственный за оценку, советуется с другими разработчиками на тему правильности оценки. Но да — ошибиться можно всегда. Я лишь говорю, как можно уменьшить ошибки.
Касательно прототипа я тоже об этом писал. Любой крупный проект стоит делать поэтапно. При этом первый этап — прототип. И оценивать тогда уже каждый последующий этап. Вот так мы об этом говорим заказчикам: www.yumapos.com/#/services/custom
Мы делаем следующим образом: оцениваем весь проект (обычно 5000-30000 человеко часов). Первый этап прототип 500-5000 часов. При этом мы заранее говорим заказчику что мы хотим иметь возможность сократить или увеличить время и бюджет проекта после завершения прототипа. Но не более 25% от первоначального бюджета. Обычно заказчики соглашаются. Если же объем новых выявленных задач во время выполнения прототипа превышает 25%, то либо начинаем подрезать где-то, либо объясняем необходимость полного пересмотра бюджета. Иногда соглашаемся на 25% увеличения и все, если маржа и так достаточно большая.
Но все равно я абсолютно уверен, что системность подхода к оценке проекта или отдельного этапа увеличивает правильность оценки. Проверено на 1000+ случаях))
Согласен. Мы пользуемся swproposal.com. Но есть еще evenflowpro.com, quoteroller.com. И еще несколько точно можно найти. Они все развиваются и полируются в плане функционала и требования заказчиков. Мы работаем для иностранного рынка, поэтому прекрасно подходит английский. Наверное со временем они локализуются. По крайней мере у нас в настройках есть выбор языка, но пока он там только один — английский.
Оценка стала реальней. Основная суть в том, на мой взгляд, что чтобы дать оценку более менее верно нужно раздробить задачу на массу взаимосвязанных подзадач. Как правило это позволяет не пропустить чего-то важного. При этом оценка точно получается точнее когда разделяешь все на мелкие части. Но да — это трудозатратно.
Там еще дополнительный вопрос. Делить все на элементы или на архитектурные части. Скажем часть разработчиков пытается делить всю работу на работы по БД, сервисы, клиентская часть. Другой подход делить все на элементы. Например, для интернет магазина это будут Home, каталог товаров, контакты и вплоть до мелких элементов таких как отдельные кнопки, контролы и т.п.
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Если терминалы работают напрямую с облаком, то по какой логике вы нумеруете заказы в случае, если у вас сеть из трех ресторанов и в каждом по 3 терминала. Нумерация сквозная или локальная по каждому ресторану? Есть ли отдельно дневной короткий номер заказа? Могли бы подробно этот момент рассказать?
1. Продавец создает карточку проекта (связанную с его клиентом или не связанную) и загружает всю имеющуюся информацию. В последствии, если появляется что-то новое, то тоже добавляет туда в виде подгруженных файлов или комментариев.
2. Технический аналитик просматривает карточку проекта, анализирует всю имеющуюся информацию и либо формирует список вопросов, либо начинает работу над технической частью проекта. При этом иногда технический аналитик проясняет все напрямую с клиентом, а иногда через менеджера продаж.
(Сразу оговорюсь, что тут я говорю про предварительную максимально точную оценку. Оценку окончательную мы даем после прототипирования, как я и писал выше.)
3. В целом, когда информации достаточно, технический аналитик создает техническую часть предложения. Имеется в виду, что он фактически последовательно заполняет поле за полем от технической части с заголовками: «в чем цель проекта», «какие основные требования», «какие возможны риски», «какие основные модули можно выделить», «подгрузите картинку с архитектурой и опишите ее» (одну или много), «выберете технологии из списка», «укажите какие виды тестирования будут применяться», «как будет осуществляться коммуникация», «укажите документацию, которая будет предоставлена с проектом» и далее непосредственно необходимо заполнить таблицу «breakdown» где указать стадии, модули, такси и саб-таски с оценкой трудозатрат и необходимую категорию специалиста (software developer, senior software developer, project manager, QA engineer и т.п.). Далее технический аналитик планирует необходимое количество людей на стадию и сроки выполнения. Переносит отдельные задачи с одной стадии на другую. Описывает конкретный результаты после сдачи каждой стадии (если их больше одной). Когда техническая часть проекта завершена, технический аналитик ставит ее в статус «complete». Фактически количество трудозатрат и сроки проекта после этого уже определены.
4. Далее начинается ответственность менеджера продаж или человека ответственного за окончательную стоимость проекта. Менеджер продаж может просматривать техническую часть, но не может ее редактировать. Он же редактирует финансовую часть. Указывает стоимость за час, скидки, налоги (если надо) и получает общий бюджет проекта. Если продаются уже созданные части, которые имеют фиксированную цену, то добавляет их. Добавляет доп. услуги в духе обучения персонала, написание обучающей документации и т.п. Получив общую стоимость, он указывает условия оплаты включая расписание оплаты и способы перечисления денег. Плюс иногда добавляет 2-3 образца портфолио и референсов клиента, и генерит предложение. Соответственно, менеджер продаж тоже указывает статус финансовой части «complete» и после этого технический аналитик уже не может ничего менять в своей оценке.
5. Ну и часто этот процесс происходит в несколько циклов. Так как в процессе переговоров клиенту приходят в голову новые идеи или он что-то сокращает, удивив цену выше возможностей. Поступают новые требования и если они существенные мы создаем новое предложения на основе созданного, а если изменения не большие, то просто корректируем созданное предложение.
На вопрос 3 я все таки уже пытался ответить. В оценке каждой задачи у нас идет отдельная задача (или несколько) на написание текстов и работу QA инженера. То есть суммарные трудозатраты по задаче включают различные виды автоматического тестирования (для разных случаев применяются разные виды) и времени тестера. Само собой когда все оценивается техническим аналитиком он держит в уме требования к надежности и скорости системы. Исходя из этого и оценивает.
Task 1 — 50 man-hours
Sub task 1 — 10 man-hours
Sub task 2 — 10 man-hours
Sub task 3 — 10 man-hours
Unit tests — 15 man-hours
QA work — 5 man-hours
Раньше мы делали все это просто в excel но потом из-за частых ошибок перешли на приложение. Но принцип тот же самый.
Мы занимаемся разработкой POS систем (www.yumapos.com). Каждая система, хоть и имеет общий функционал, уникальна и требует отдельного осмысления и последующей оценки трудозатрат. Средний разброс, как я писал выше, 5000-30000 часов. Последний раз я оценил систему в 27000 часов. И вот при оценке подобной системы мы не можем начать объяснять, что для того чтобы оценить нам нужно сделать прототип. Заказчик хочет сказать что ему надо и через несколько дней получить сроки и бюджет. Мы в этом случае, конечно, каждый раз работаем с более менее понятной для нас областью. Но размер проекта все равно требует усилий по детальной оценке. Скажем в последнем проекте, который я оценивал, было 29 модулей и еще 4 отдельным мобильных приложения с поддержкой четырех платформ (web, desktop, iOS, Android). Изначально показалось (как часто бывает), что проект максимум на 10000 часов. Но когда стал считать и прояснять мелочи получилось 27000.
Вот с чем я работаю. Я рассказал, чтобы Вы понимали мою ситуацию. У каждого она все таки индивидуальная.
Теперь отвечу на Ваши вопросы:
1. Мы разбиваем проект на этапы по следующим принципам
— первый этап — прототип, второй — создание базового функционала, третий и последующие — добавление и расширение функционала. При этом после выполнения прототипа мы корректируем все планы, чтобы они соответствовали всей имеющейся информации после создания прототипа. Корректируем бюджет и сроки.
— второй принцип заключается в том, что этапы я стараюсь разбивать не больше, чем 2-3 месяца работы, чтобы процесс оплаты протекал плавно.
— третий принцип — заказчик после каждого этапа должен видеть результаты работы. Рассказ, что мы написали всю серверную часть, которую не видно, потому что нет интерфейса не работает. Заказчик всегда хочет понимать за что он платит и так как он не программист чаще всего, лучше чтобы после каждого этапа были видимые результаты работы.
— четвертый принцип — задачи нужно разбивать настолько мелко, чтобы каждую можно было выполнить в пределах 1-10 часов.
2. Если Вы имеете в виду внедрение CRM типа MS Dinamix для заказчиков, то мы этим не занимаемся. Мы делаем проекты разработки с нуля, а также проекты когда мы разрабатываем часть Point of sale системы, а часть продаем готовые модули. Но чаще всего разработки с нуля не менее 50%. Если вопрос в том, какую CRM мы используем, то это тот функционал, что есть в swproposal.com. Она там не супер функциональная. Скорее простая. В основном мы храним информацию о клиенте и трекаем статус отношений с ним. Подгружаем файлы. На каждого клиента создаем проект и предложение или несколько предложений и также отслеживаем процесс переговоров по ним. Сразу извиняюсь, если я не совсем о том. До конца вопрос Ваш не понял.
3. Обычно мы разделяем объем работы на модули (например раздел Customers, Inventory, Orders liss). Далее делим на крупные задачи в рамках модуля (Customers groups management, customer form, и т.п.) и далее уже делим на мелкие задачи и подзадачи, чтобы каждая задача была 1-10 человеко часов. Если проект подразумевает этапы, то мы распределяем полученный лист задач на разные этапы.
4. Первоначально мы занимались разработкой всего, что могли найти. Были веб социальные проекты, мессенджеры, веб приложения для автоматизации бизнес процессов, CRM и много чего еще. Тогда мы начали работу по организации процесса оценки. Ранее оценивал просто программист на основании собственного опыта и собственной тщательности. Разные программисты давали сильно разные оценки и разную детализацию проекта. Однажды мы продали проект за 3 человеко-месяца, а делали около года. Сейчас ошибки бывают, но это не катастрофические ошибки и не выходят за пределы 20%. То, что мы сделали — заставили всех, кто участвует в продажах и оценке проектов действовать по утвержденным шагам с детализированной оценкой проекта. Так чтобы все большие задачи разбивались на логично взаимосвязанные маленькие с их последующей оценкой. Это сокращает вероятность ошибки.
5. Коммуникация, конечно, возросла. Но и возрос процент полученных проектов из тех, что мы оценивали подробно.
Касательно прототипа я тоже об этом писал. Любой крупный проект стоит делать поэтапно. При этом первый этап — прототип. И оценивать тогда уже каждый последующий этап. Вот так мы об этом говорим заказчикам: www.yumapos.com/#/services/custom
Мы делаем следующим образом: оцениваем весь проект (обычно 5000-30000 человеко часов). Первый этап прототип 500-5000 часов. При этом мы заранее говорим заказчику что мы хотим иметь возможность сократить или увеличить время и бюджет проекта после завершения прототипа. Но не более 25% от первоначального бюджета. Обычно заказчики соглашаются. Если же объем новых выявленных задач во время выполнения прототипа превышает 25%, то либо начинаем подрезать где-то, либо объясняем необходимость полного пересмотра бюджета. Иногда соглашаемся на 25% увеличения и все, если маржа и так достаточно большая.
Но все равно я абсолютно уверен, что системность подхода к оценке проекта или отдельного этапа увеличивает правильность оценки. Проверено на 1000+ случаях))
Там еще дополнительный вопрос. Делить все на элементы или на архитектурные части. Скажем часть разработчиков пытается делить всю работу на работы по БД, сервисы, клиентская часть. Другой подход делить все на элементы. Например, для интернет магазина это будут Home, каталог товаров, контакты и вплоть до мелких элементов таких как отдельные кнопки, контролы и т.п.