Кейс "Задание на разработку"
Функциональные - Управление проектом (PMO, EPM)
Файлы
ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.
Подписка PRO — скачивайте любые файлы со скидкой до 85% из Базы знаний
Оформите подписку на компанию для решения рабочих задач
Оформить подписку и скачать решение со скидкойВы можете заказать платную доработку или адаптацию этой разработки под вашу конфигурацию на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
Первый лист - титульный. Никаких строк согласования не требуется. Достаточно приведенных параметров. Можно еще какую-нибудь картинку для красоты добавить.
Далее, история изменений. Мы ведь тоже не идеальны и с первого раза можем ТЗ только клиенту сдать. А наш коллега всегда найдёт в чём мы не правы. Ему же делать. Так что сразу планируйте минимум 3 итерации. Или 3 версии. И еще, желательно в колонке "состав изменений" писать понятно. Можно подробно.
Теперь обозначаем главную проблему, делаем привязку к срокам, платформе, конфигурации, режиму работы. Связанным задачам, которые нужно решить в рамках данного задания
Конечно же термины, проекты, у нас разные, из разных отраслей. Иногда попадаются специфические названия. Надо, ну надо дать расшифровку для программиста. Да и сами лучше понимать будете. Клиенту опять же будет что на презентации сказать. Ввернуть, так сказать, милые его уху словечки.
Здесь чистая литература. Как получится. Желательно выявить не только проблему, но и причины ее появления.
Входите в режим "бога" и предлагаете РЕШЕНИЕ. Возможно даже правильное.
Это вообще бесподобно. Вы предлагаете не только решение, но и способ как его реализовать. Но особо не настаивайте, можно придумать его вместе с программистом. Ему приятно, да и Вам попрактиковаться в командообразовании надо.
Показываем кто в доме хозяин и почему именно Вы занимаете эту должность. Лишний раз продемонстрировать Ваши навыки совсем не помешает. Смысл, правда, тоже желательно чтобы был. Про логику напоминать надо?
Да, да. Вы, как бы, влезаете в шкуру конечного пользователя и пытаетесь мысленно продумать последовательно шагов. Сложно? Посмотрите фильм "Бойцовский клуб" или "Плутовство или хвост виляет собакой". В этот момент надо представить конкретного человека на стороне заказчика, который будет работать с Вашим РЕШЕНИЕМ. Ощутили его эмоции? Не стыдно? Тогда вперед.
Закончили с прелюдией. Теперь переходим к конкретике. Делаем карточку с общей информацией для каждого связанного задания. Учитываем особенность. Что это? Регистр сведений, накопления, обработка, отчет, документ, справочник? от этого будет зависеть структура параметров в карточке.
Теперь описываем структуру данного объекта. Побольше уверенности. Если что, Вам непременно укажут на Ваши ошибки, и вы сделаете новую версию задания.
Если в задании несколько сквозных задач - описываем каждое из них отдельно. Сначала карточку с общей информацией
Затем структуру. Вспоминаем фильм. "В себя веришь? Верю. Цель видишь? Вижу"
Задание предполагает интерфейс пользователя. Что ж, значит надо заняться прототипированием. В первой версии задания, достаточно использовать скан обычного листа бумаги с Вашим творчеством. В последующих версиях заменить рисунки на скрин-шоты реальных форм. Опять таки - думаем о пользователе!!! Ему работать!
Я делаю примерно так:
1. Сначала рисую интерфейс на бумаге А4 в разных вариантах. Выбираю подходящий
2. Делаю в конфигураторе форму без обработчиков событий. Типа скелет. Затем отсылаю задание и скелет обработки программисту. Он наполняет ее смыслом, кодом, матюгами.
3. Я тестирую и вставляю программисту за невнимательность. Иногда всё работает с первого раза.
Интерфейс можно условно разделить на блоки. Какие? обозначьте их. Опишите их
Далее, каждый блок расписываем подробненько по функциям.
И так для каждого блока
Если задача предполагает заполнение некой третьей формы со своими реквизитами - сделайте табличку по правилам заполнения каждого нужного реквизита. Реквизиты которые не заполняются и не влияют на работоспособность формы не указываем. Помним - воду не льем.
То же самое делаем для реквизитов табличных частей, если они имеются.
В принципе, этого достаточно. Но можно дополнить задание космосом:
- добавить сценарии тестирования
- показатели успешности (KPI) - чтобы оценить насколько улучшилась работа заказчика. Сколько он сэкономил, насколько увеличилась его производительность и упала трудоёмкость.
Сколько времени надо на формулировку одного задания? 8 часов. 1 рабочий день и одна ночь, вдруг какие умные мысли придут. Если опыта мало умножайте на 3.
Приложение: файл "Задание на разработку.pdf"
p.s.: присоединяйтесь к группе "Записки внедренца 1С" тут
Вступайте в нашу телеграмм-группу Инфостарт
Частное техническое задание ЧТЗ Задание на разработку задание программисту
См. также
Управление проектом (PMO, EPM) Аналитик Руководитель проекта 1С:Предприятие 8 Платные (руб)
Решение предназначено для эффективного учета и управления проектами внедрения 1С:ERP. Эта конфигурация содержит все необходимые инструменты для успешной реализации сложных проектов. Дорожные карт, сбор требований, функциональное моделирование, ТЗ, тесты и Service Des - в единой базе. Ускоряет запуск, повышает качество и прозрачность работ над проектом, снижает зависимость от «незаменимых» сотрудников. Эффективна при переходе с SAP/УПП на 1С:ERP.
268400 руб.
01.02.2023 9792 2 2
Управление проектом (PMO, EPM) Разработчик 1С 8.3 Абонемент ($m)
Практический регламент для 1С-разработчиков и команд, выполняющих доработки типовых конфигураций по договору подряда. Разбираем юридические и технические границы: предмет с фиксацией релиза, сценарная приёмка, гарантия при обновлениях типовой конфигурации и права на код по ГК РФ. В статье: чек-лист рисков, образцы формулировок и готовый пакет документов в архиве-компаньоне.
5 стартмани
14.10.2026 324 Ninel_S 0
Управление проектом (PMO, EPM) Тестирование QA Разработчик Руководитель проекта 1С 8.3 Абонемент ($m)
Инженерный регламент для команд, разрабатывающих на платформе «1С:Предприятие» для зарубежного заказчика: правовые границы удалённого доступа (EDPB, регуляторные ограничения), построение строгого контракта данных (Data Contract) и независимая проверяемая приёмка выгрузок. В архиве-компаньоне — готовый офлайн-валидатор на Python с защитой от ошибок округления Decimal, эталонные наборы и криптографическая фиксация SHA-256.
1 стартмани
12.10.2026 300 Ninel_S 0
Управление проектом (PMO, EPM) Разработчик Руководитель проекта 1С 8.3 1С:Франчайзи, автоматизация бизнеса Абонемент ($m)
Предпроектная оценка 1С-проекта как фильтр убыточных заказов: пять зон проверки (учётная политика, состояние базы, обмены, компетенции, сроки), письменное заключение с оценкой работ и три варианта отказа, после которых заказчик возвращается. Числа в примерах условные, ставок и процентов нет: вместо них признаки риска, которые можно проверить на своей базе, и метрики фильтра.
1 стартмани
05.10.2026 432 Ninel_S 0
Управление проектом (PMO, EPM) Руководитель проекта Бесплатно (free)
Как распределить ответственность между руководителем проекта, архитекторами и исполнителями, зачем раздельно учитывать задачи аналитики и разработки и как использовать план-факт и КПД не как рейтинг сотрудников, а как инструмент управления проектом.
25.09.2026 1253 OlgaGroo 4
Управление проектом (PMO, EPM) Россия Бесплатно (free)
1С-разработчик работает удалённо, получает задачи от тимлида, ходит на daily, пользуется VPN и корпоративной почтой, а каждый месяц получает одну и ту же сумму. Это ещё подряд или уже обычная работа в штате? Разбираем на двух противоположных IT-делах, включая спор 1С-программиста, дошедший до Верховного Суда.
15.09.2026 1140 NikolayMaerov 0
Управление проектом (PMO, EPM) Аналитик Руководитель проекта Бесплатно (free)
Ведущий аналитик еще пишет требования и разбирает сложные вопросы, но параллельно начинает собирать статусы, разруливать загрузку команды, напоминать коллегам о сроках, готовить клиентские встречи и отвечать за то, чтобы проект вообще двигался. В какой-то момент аналитической работы у него остается все меньше, а проект фактически получает второго руководителя — только без формально закрепленных полномочий. Разбираю, по каким признакам это видно и как вернуть границы роли, не развалив работу команды.
14.09.2026 933 YA_826532418 0
Управление проектом (PMO, EPM) Россия Бесплатно (free)
Работодатель запретил разработчику два года работать у конкурентов и клиентов, а за нарушение назначил миллионный штраф. Разбираемся по свежей судебной практике, работают ли такие условия в России
11.09.2026 1657 NikolayMaerov 4
1) "СВОЕМУ" - что Вы вкладываете в это понятие?
2) Для кого написана эта статья?
2) для консультантов, архитекторов, руководителей проектов. Зависит от разделения функций на проекте.
Точно так же и в Вашей компании - Вам дают образец или последний хороший документ, который готовили и "делай как тут".
(0) Если у вас на фирме кодер - гоните в шею и наймите программиста.
Программист сам будет знать какой регистр сведений надо создать и с какими реквизитами, а отчет об новых объектах - это отчет из хранилища.
Программистам должна ставиться не задача, как таковая, а разъяснение того, что вы хотите получить в конце. А он сам придумает как сделать.
С новыми программистами, удаленщиками и фрилансерами - подробная формализация.
Если вы нанимаете программиста, то вы ему должны изложить суть, он сам найдет подход.
А что толку, вы дали ему чуткое руководство к действию, он без понимания - тупо это делает, а потом будет пытаться туда что то навязать.
Самое веселое - если вы в таком подробном ТЗ допустили ошибку. Вот это весело будет. Кто тогда виноват?
Но а если мы говорим про студента, то тогда так и статью назовите "Руководство действия для чайника".
Везде есть риски, водитель тоже может быть профи, но в итоге врезаться во что то или опоздать на какое то время к пункту прибытия.
1) дать подробную инструкцию
2) дать задание и ждать решение.
Вопрос: Какой из двух подходов предпочтительней?
Нет ответа - зависит от специфики проекта, привлекаемых ресурсов, личных навыков
Если нет знаний на уровне платформы, сам никогда код не писал, то тогда конечно второй подход. А если твой опыт достаточен для проектирования систем - тогда первый. Для этого и вводится позиция Архитектора. Нет у меня времени на пальцах объяснять очевидные мне вещи программисту - я хочу получить результат в нужные мне сроки. Я отвечаю за функциональность системы. Не программист. Он в офисе сидит, я у клиента систему сдаю. Нужны мне неожиданности?
Другая ситуация - мне дали программиста. Ок, отлично, только мне нужно выполнить работы в рамках производственного контура, а он последние 3 года автоматизировал только магазины. Вопрос, надо ли давать ему возможность самому придумывать решение. Однозначно Нет - у него недостаточно опыта в предметной области.
И еще момент: в каждой ИТ компании недостаток специалистов. В каждой. Никаких предпосылок, что проблема в ближайшие годы будет решена нет.
С другой стороны есть армия программистов, которые сидят на своем месте, получают зарплату, загрузка у них не очень большая и они вполне могут взять халтуру. Чтобы использовать данный ресурс, надо точно формулировать задачу.
я к тому, что остальное - не обязательно
**
учитывая справедливое (иногда) - замучает - предыдущего оратора, иногда даже и вредно
(в таких случаях хочется сказать - если ты такой умный - сделай это уже)
Мне за свою бытность довелось:
1) Набраться опыта работая программистом на заводе
2) 5 лет руководить внедрением и разработкой ERP системы "Финансовая коллекция" на базе Oracle (сейчас используются в 5-ти энергетических компаниях Украины)
3) 5 лет сопровождать этот продукт в Харьковоблэнерго в качестве руководителя секторов "Бухгалтерских задач" и "Администрирования БД Oracle"
4) 4 года
Внедрять УПП, УТП. Руководить разработкой и продвижением сайтов.
5) 4 года разрабатываю и внедряю собственную конфигурацию.
За это время прошел стадии:
Программиста,
Руководителя проектами,
Архитектора
Консультанта
Web-разработчика
Собственника
Бизнес-аналитика
И снова Программиста.
И со всей ответственностью заявляю - Вы чертовски ПРАВЫ! Просто не успел Вас плюсануть ;)))
Со стороны программиста Ваш взгляд на руководителя, с моей точки зрения вполне адекватный.
Между нами кроликами, я сам чуть не напросился к verter.me пофрилансить )))))))) см (30)
Верьте только себе и своему опыту.
2) дать задание и ждать решение.
Нет черного и белого. Есть множество Вариантов между п1 и п2, некоторые из них подходят лично Вам.
Кроме этого - я прошел через часть этих стадий, в частности от программиста, до руководителя, далее собственника, а теперь работаю с напарниками в нами же созданной фирме - обычными программистами :)
таки в первых обстоятельства довлеют
личностные качества либо адекватны, либо нет
ну, т.е. под 1снега, РП ли, кодера ли, мир прогибаться не будет
да и макаревич скорее пассивен в результате :)
пс: (50) - прекрасная иллюстрация
(48) DitriX,
Андрей. У Вас сильная Харизма, у Вас Великий Дар - убеждать. Ради бога - поосторожнее...
За статью спасибо. Выслал её "СВОЕМУ" бывшему программисту как шаблон.
У него сегодня в конце дня дебют: встреча с реальным заказчиком один на один.
Передает Вам свою благодарность.
По поводу раздолбая и поганца. Статья хорошая, а вот соус под которым она подана - не очень.
Давайте относиться друг к другу с Уважением, стоить схему отношений не Руководитель vs Программист, а
Руководитель & Программист. Даже, если парень "раздолбай", объясните ему, что его легкомысленное отношение,
дает возможность заказчику повесить на него всех собак.
Что в этом случае он будет, как минимум работать и выгребать за троих: за себя, за вас и за заказчика, а получит зп только за себя,если конечно проект будет сдан во время и в рамках бюджета.
Надеюсь аннотация к статье скорее результат куража после дня программиста, а не устойчивая и осознанная позиция Руководителя.
Анализ эффективности применения данного подхода:
С ваших слов, затратив 8 часов времени своего времени, вы определяете фронт работ программисту на 15 часов.
Таким образом, в лучшем случае вы можете управлять 2-мя программистами. А пользу вы когда приносить будете?
Нужно еще с заказчиком пообщаться. Договора оформить. Проект сдать. Деньги получить?
Таким методом, вы можете работать силами одного программиста. В общем как - то так выходит.
Обычно я придерживаюсь следующих норм времени:
1) 25% на постановку задачи;
2) 50% на проектирование;
3) 15% на кодирование;
4) 10% на тестирование.
Применительно к вашему случаю, вы взяли на себя выполнение пункта 1 и 2, то есть 70% работы и заложились в 8 часов
Кодеру дали возможность 15 часов делать 15% от общего объема работ. В шею такого кодера!
Если он не сделает работу за 2 часа - с вещами на выход!
В остальном согласен, проектная группа состоит примерно из 4-х человек: РП, архитектор, консультант, программист. Этого достаточно, чтобы поднимать проекты с годовой выручкой около 40 млн.
Если проект меньше, то функции РП и Архитектора объединяем.
Если еще меньше, то консультант идет в сад. функция ложится на РП
Согласен, соотношение - не догма. В реальной жизни 1 к 3 и получается ;)
По поводу проектной группы с выручкой в 40 млн, то же согласен.
Хотя и контекста статьи вытекало, что их всего двое: РП+Программист.
В случае с УПП добавил бы еще одного программиста, уж больно УПП неворотлива.
А то Пользователей жалко и Консультанта - в рукопашную до ночи данные калашматить.
А но то прикольно получается, смотреть как люди на износ работают...
Мне нравится, когда проект в срок сдается, и люди вовремя домой уходят.
Любопытно было бы взлянуть, вот ни разу Экспресс обследование не давало реальной картины.
Пока три месяца на предприятии не поваришься - границы проекта размыты до нельзя.
Так, что если не коммерческая тайна - выкладывайте, будет интересно!
ага, СПС... видел... отметился ещё 01.09.13. На досуге перечитаю ;)
Что делать? Действительно, как уже высказались Tango и DitriX нанимаем нормального программиста к себе в офис, что бы был всегда под рукой.
PMBOK4 сжигаем на костре. Вместо нее берем за основу берем методику Agile.
Напиваемся в усьмерть с новым программистом. Одно из двух: либо вы столкнетесь с неразрешимыми противоречиями,
либо перейдете на другой уровень общения и взаимопонимания.
По поводу самой постановки задач. Кривовато, как-то:
1 час на создание регистра и 15 на обработку... а изменение документа где?
По моему адекватнее было бы так:
0,5 часа на создание регистра
0,5 часа на реализацию события "ОбработкаПроведения"
1 час на разработку Обработки
0,5 часа на тестирование
0,5 на отдых.
нееее... ну это меняет дело, просто из статьи это не вытекает. Вы многие моменты пропустили. В таком случае в разделе "Норматив времени нужно было указать не 15, а допустим 4". Разницу программисту выдать в конце месяца в виде премии ;)))
Исходя из выше изложенного я бы по пунктам вашего кейса поступил бы следующим образом:
1.ИСТОРИЯ ИЗМЕНЕНИЯ ДОКУМЕНТА
2.КАРТОЧКА ЗАДАНИЯ
3.ТЕРМИНЫ
4.ОПИСАНИЕ ПРОБЛЕМНОЙ ОБЛАСТИ
5.РЕШЕНИЕ
6.СПОСОБ РЕШЕНИЯ
7.КОНЦЕПТУАЛЬНАЯ СХЕМА
8.АЛГОРИТМ ДЕЙСТВИЙ
9.1 ЗАДАЧА №1 СОЗДАТЬ РЕГИСТР СВЕДЕНИЙ "ТОВАРНЫЕ ГРУППЫ ПОСТАВЩИКОВ"
Карточка
Измерения
Ресурсы
9.2 ЗАДАЧА №2 РАЗРАБОТАТЬ ОБРАБОТКУ "УПРАВЛЕНИЕ СКИДКАМИ"
Реквизиты
Форма обработки
Структура
Раздел "Управление скидками";
Раздел "Подвал"
Алгоритм заполнения документа "Установка скидки номенклатуры"
10.Добавить сценарии тестирования
11.Показатели успешности (KPI)
============================================
1.ИСТОРИЯ ИЗМЕНЕНИЯ ДОКУМЕНТА - оставить как есть.
2.КАРТОЧКА ЗАДАНИЯ - оставить как есть.
3.ТЕРМИНЫ - перенес бы в корпоративный стандарт, оставил бы специфические для предметной области
4.ОПИСАНИЕ ПРОБЛЕМНОЙ ОБЛАСТИ - разрабатывал совместно с заказчиком
5.РЕШЕНИЕ - делегировал бы разработчику
6.СПОСОБ РЕШЕНИЯ - делегировал бы разработчику
7.КОНЦЕПТУАЛЬНАЯ СХЕМА - сделал бы сам
8.АЛГОРИТМ ДЕЙСТВИЙ - Заменил на РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ
9.ПОСТАНОВКУ ЗАДАЧ - делегировал бы разработчику, с требованием вести документацию хотя бы в стандартах
IDEF1X применительно к документам, справочникам и регистрам.
По большому счету, хорошо бы с самого начала иметь такую документацию на конфигурацию. Здорово экономит время
на общение по деталям.
10. Контрольный пример потребовать от заказчика на этапе описания предметной части, чтобы выявить ошибки постановки задачи на раннем этапе.
11. На (KPI) - Забить!!! Это от лукавого, по крайней мере в данном случае.
Приношу извинения за резкий тон. Просто хотелось бы кратко и по существу. Ваша статья несет большую полезную нагрузку и для новичков и для профессионалов.
Респект Вам и Уважуха. С удовольствием читаю ваши статьи. Просто в данном случае у нас с вами слишком большая разница в подходах. Надеюсь до холиварщины не дойдет.
К сожалению, когда у Вас параллельно идет несколько проектов, то приходится передавать часть своих умений на сторону. А чтоб не получить в обратку поток кучи вопросов - делаю формализацию.
Т.О. при определенной сноровке, один день формализации загружает примерно двух программистов в течении 3-4-х дней. Соответственно неделя формализации даёт месячную загрузку проектной команды. Плюс появляется инструмент для контроля выполнения.
PS: пошел на форум писать про то чтобы добавили раздел кейсы, а то доминикану добавили, кейсы то нужнее в разы чем фото с тая )
1. Таблица - некая логическая табличная сущность;
2. Документ - под этим он понимал печатную форму какого либо документа (ТОРГ 12, СФ и пр.), причем если печатных форм несколько, то это для него было несколько документов.
3. Отчет - здесь очень близко к реальности - отчет с настройками и неким результатом.
И это по большому счету все!
По началу я пытался его обучить использовать терминологию 1С, чему он не возражал в общем, но продолжал использовать исключительно свою терминологию.
В результате, по степени проработки деталей, объему логики, удобству и стабильности работы это до сих пор не превзойденная конфигурация из тех, что я видел.
Вобщем есть форма, а есть содержание...
2. Документ - под этим он понимал печатную форму какого либо документа (ТОРГ 12, СФ и пр.), причем если печатных форм несколько, то это для него было несколько документов.
3. Отчет - здесь очень близко к реальности - отчет с настройками и неким результатом.
И это по большому счету все!
это - да. в таком объеме юзерские сущности и имеют место быть. упорным трудом удается внедрить в ихнее сознание понятие "диалог" как экранной формы
Но для приведенного примера, по небольшой задачке на доработку тратить 8 часов на постановку задачи...
Это уж черезчур, опять-таки, ИМХО. Особенно если программист "СВОЙ". Если есть риск оппортунизма со стороны "внешних" программистов, то как средство защиты и минимизации рисков прокатит... Хотя, опять-таки, если на Вас работает команда фрилансеров-однозадачников (не длительное сотрудничество), то какая разница? Не сделали так как нужно было - не получили ЗП (конечно, в таком случае возникает проблема срыва сроков, но опять-таки, экономится время на постановку задачи... и, за что всегда ратую: КЛИЕНТУ ЗАЧАСТУЮ ПЛЕВАТЬ НА СРОКИ - так почему бы не назвать "с запасом"? Задачка на 1 день - называем 2-3 дня и имеем гарантию от "криворукости" фрилансера).
Мне стало интересно, не сколько даже ради денег, а идея понравилась. Я может бы даже бесплатно работал, денег мне и так, как бы, хватает.
А вы вместо того, что бы просто сказать что-то типо "извини, давай может через годик свяжемся?", просто оборвали беседу. Я не в обиде, но ваш поступок, на фоне ваших статей, был для меня шоком. :)
Было допущено несколько серьезных проколов. Надо было решить важную задачу - обеспечить текущий доход. Чуть было даже не пошел работать по найму.
Морально сильно просел. На проект смотреть не мог, не то что сотрудничать с кем-то.
Проект был почти на грани закрытия. Даже статьи писать не мог.
Парадокс в том, что чужой бизнес оптимизировать намного проще, чем строить свой. Даже имея необходимые знания.
Сейчас всё налаживается
Тоже с удовольствием прочел все статьи и что-то для себя в них увидел.
Как периодически фрилансящий фикси хочу сказать, что грамотная (как в статье) постановка задачи - это огромный плюс. Такое встречается очень редко. Обычно привыкаешь догадываться за постоянного клиента, что он имеет в виду. Но по-первости тратишь кучу своего времени на переделки.
Не знаю, не проверял. Данную методику только только оформил в готовом виде. До этого делал как всегда: устно ставил задачи, что-то писал, что-то рисовал. А вот теперь понадобилась.
Какое количество программистов? Давайте прикинем
Итак: для оформления одного задания нужно 8 часов или 1 рабочий день. Одно задание для 1 программиста. Одно задание ему на 24 часа, т.е. 3 рабочих дня. Я взял соотношение 1 к 3.
Т.О. за 5 дней можно подготовить 5 заданий и загрузить программиста на 15 рабочих дней. Плюс 5 дней на тестирование. Получается полный месяц.
Если брать полный месяц под формализацию, то можно загрузить до 4 программистов. Наверное.
Делаем вывод: Работа одного специалиста по формализации задач (консультант? архитектор?), может дать работу 4 программистам. Если учесть выходные, то можно и 5-го впихнуть.
Год назад мне дали полдесятка необученных программистов. Чтоб избежать сюрпризов и не переделывать все самому в последний момент, решил применять подобный подход. Столкнулся с такими трудностями:
- Случалось, что ребята делали работу быстрее чем я успевали успевал ставить задачи.
- Если была работа, которую не мог поручить другим, то методика рушилась. Ребята или простаивали или приходилось довериться им и периодически давать им подсказки.
- При 4-х программистах консультант должен быть хорошего уровня. Иначе нужно его подстраховывать и снова методика рушится.
Пришел к выводу, что в команде программистов должен быть хотя бы один человек, в чьей квалификации я полностью уверен и кому могу доверить часть разработки.
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 200938
Создание 16.09.13 13:39
Обновление 16.09.13 13:39
Просмотры 55673
Загрузки 46
Рейтинг
45
Комментарии 60
Код открыт Не указано
Рубрики Управление проектом (PMO, EPM)
Кому
Разработчик
,
Пользователь
Тип файла Архив с данными
Платформа 1С:Предприятие 8
Конфигурация 1С:Управление производственным предприятием
Операционная система Windows
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Абонемент ($m)
