И ведь он, поганец такой, требует, чтоб ему дали конкретную работу. И не грузили всякой ерундой и не лили воду на мельницу.
В идеале, было бы вообще замечательно, если бы можно было бы из технического задания, которое мы подготовили для клиента, нарезать небольшие задания и раздавать их разным исполнителям. А затем в проджекте галочки об исполнении ставить.
Но ведь нет, на практике же приходится давать устные пояснения по каждому пункту. Объяснять, что имелось в виду вот в этом предложении ТЗ в тот момент, когда его формулировал для клиента.
Вот и предлагаю способ сохранить нервы себе и уверенность в Вас со стороны программиста.
Первый лист — титульный. Никаких строк согласования не требуется. Достаточно приведенных параметров. Можно еще какую-нибудь картинку для красоты добавить.
Далее, история изменений. Мы ведь тоже не идеальны и с первого раза можем ТЗ только клиенту сдать. А наш коллега всегда найдёт в чём мы не правы. Ему же делать. Так что сразу планируйте минимум 3 итерации. Или 3 версии. И еще, желательно в колонке «состав изменений» писать понятно. Можно подробно.
Теперь обозначаем главную проблему, делаем привязку к срокам, платформе, конфигурации, режиму работы. Связанным задачам, которые нужно решить в рамках данного задания
Конечно же термины, проекты, у нас разные, из разных отраслей. Иногда попадаются специфические названия. Надо, ну надо дать расшифровку для программиста. Да и сами лучше понимать будете. Клиенту опять же будет что на презентации сказать. Ввернуть, так сказать, милые его уху словечки.
Здесь чистая литература. Как получится. Желательно выявить не только проблему, но и причины ее появления.
Входите в режим «бога» и предлагаете РЕШЕНИЕ. Возможно даже правильное.
Это вообще бесподобно. Вы предлагаете не только решение, но и способ как его реализовать. Но особо не настаивайте, можно придумать его вместе с программистом. Ему приятно, да и Вам попрактиковаться в командообразовании надо.
Показываем кто в доме хозяин и почему именно Вы занимаете эту должность. Лишний раз продемонстрировать Ваши навыки совсем не помешает. Смысл, правда, тоже желательно чтобы был. Про логику напоминать надо?
Да, да. Вы, как бы, влезаете в шкуру конечного пользователя и пытаетесь мысленно продумать последовательно шагов. Сложно? Посмотрите фильм «Бойцовский клуб» или «Плутовство или хвост виляет собакой». В этот момент надо представить конкретного человека на стороне заказчика, который будет работать с Вашим РЕШЕНИЕМ. Ощутили его эмоции? Не стыдно? Тогда вперед.
Закончили с прелюдией. Теперь переходим к конкретике. Делаем карточку с общей информацией для каждого связанного задания. Учитываем особенность. Что это? Регистр сведений, накопления, обработка, отчет, документ, справочник? от этого будет зависеть структура параметров в карточке.
Теперь описываем структуру данного объекта. Побольше уверенности. Если что, Вам непременно укажут на Ваши ошибки, и вы сделаете новую версию задания.
Если в задании несколько сквозных задач — описываем каждое из них отдельно. Сначала карточку с общей информацией
Затем структуру. Вспоминаем фильм. «В себя веришь? Верю. Цель видишь? Вижу»
Задание предполагает интерфейс пользователя. Что ж, значит надо заняться прототипированием. В первой версии задания, достаточно использовать скан обычного листа бумаги с Вашим творчеством. В последующих версиях заменить рисунки на скрин-шоты реальных форм. Опять таки — думаем о пользователе!!! Ему работать!
Я делаю примерно так:
1. Сначала рисую интерфейс на бумаге А4 в разных вариантах. Выбираю подходящий
2. Делаю в конфигураторе форму без обработчиков событий. Типа скелет. Затем отсылаю задание и скелет обработки программисту. Он наполняет ее смыслом, кодом, матюгами.
3. Я тестирую и вставляю программисту за невнимательность. Иногда всё работает с первого раза.
Интерфейс можно условно разделить на блоки. Какие? обозначьте их. Опишите их
Далее, каждый блок расписываем подробненько по функциям.
И так для каждого блока
Если задача предполагает заполнение некой третьей формы со своими реквизитами — сделайте табличку по правилам заполнения каждого нужного реквизита. Реквизиты которые не заполняются и не влияют на работоспособность формы не указываем. Помним — воду не льем.
То же самое делаем для реквизитов табличных частей, если они имеются.
В принципе, этого достаточно. Но можно дополнить задание космосом:
— добавить сценарии тестирования
— показатели успешности (KPI) — чтобы оценить насколько улучшилась работа заказчика. Сколько он сэкономил, насколько увеличилась его производительность и упала трудоёмкость.
Сколько времени надо на формулировку одного задания? 8 часов. 1 рабочий день и одна ночь, вдруг какие умные мысли придут. Если опыта мало умножайте на 3.
Приложение: файл «Задание на разработку.pdf»
p.s.: присоединяйтесь к группе «Записки внедренца 1С» тут
Related Posts
Оценка и планирование проекта
Мысли о видах информационных систем…
Конфигурация "Выдача пропусков и учет рабочего времени"
Управление ИТ-проектами. Модуль 3: продвинутый курс по гибкому управлению проектами. Agile. Первый поток. Вебинары проходят с 11 сентября по 27 ноября 2024 г.
Загрузка/Выгрузка Excel для справочника "Графики работы сотрудников"
Онлайн-курсы по управлению ИТ-проектами от Марии Темчиной
Все замечельно, ясно и понятно. Вот только можно два вопроса?
1) «СВОЕМУ» — что Вы вкладываете в это понятие?
2) Для кого написана эта статья?
1) СВОЙ программист, это специалист, которому Вы ставите задачу. Т. Е. Вы постановщик задач, исполняют их другие люди. Иногда они находятся на удалённой работе. Но так или иначе они получают от Вас зарплату и отвечают за исполнение поставленных им задач.
2) для консультантов, архитекторов, руководителей проектов. Зависит от разделения функций на проекте.
Это не «кейс», а наглядный пример…
(3) AnryMc, Пусть будет так. Словом «кейс», я обозначаю статьи, материал которых можно использовать в своей деятельности, без лишней заумности.
Точно так же и в Вашей компании — Вам дают образец или последний хороший документ, который готовили и «делай как тут».
Спасибо, возьмем на заметку
Небольшое замечание по скриншотам:
Описание проблемной области
…много времени тратит(без Ь)ся…
Решение
…тем быстрее документ будет проводит(с Ь)ся…
Все красиво. Маленькая грабля: детализируя тз кодеру до такой степени, автор практически выполнил разработку. Заполнить нужные места нужным кодом — времени уйдет на порядок меньше, чем передавать эту детализацию кодеру (а потом еще и принимать обратно, и не факт — что кодер при этом заполнит нужные места нужным кодом).
(7) полностью согласен.
(0) Если у вас на фирме кодер — гоните в шею и наймите программиста.
Программист сам будет знать какой регистр сведений надо создать и с какими реквизитами, а отчет об новых объектах — это отчет из хранилища.
Программистам должна ставиться не задача, как таковая, а разъяснение того, что вы хотите получить в конце. А он сам придумает как сделать.
Сообщение №1
За статью спасибо. Выслал её «СВОЕМУ» бывшему программисту как шаблон.
У него сегодня в конце дня дебют: встреча с реальным заказчиком один на один.
Передает Вам свою благодарность.
Сообщение №2
По поводу раздолбая и поганца. Статья хорошая, а вот соус под которым она подана — не очень.
Давайте относиться друг к другу с Уважением, стоить схему отношений не Руководитель vs Программист, а
Руководитель & Программист. Даже, если парень «раздолбай», объясните ему, что его легкомысленное отношение,
дает возможность заказчику повесить на него всех собак.
Что в этом случае он будет, как минимум работать и выгребать за троих: за себя, за вас и за заказчика, а получит зп только за себя,если конечно проект будет сдан во время и в рамках бюджета.
Надеюсь аннотация к статье скорее результат куража после дня программиста, а не устойчивая и осознанная позиция Руководителя.
Сообщение №3
Анализ эффективности применения данного подхода:
С ваших слов, затратив 8 часов времени своего времени, вы определяете фронт работ программисту на 15 часов.
Таким образом, в лучшем случае вы можете управлять 2-мя программистами. А пользу вы когда приносить будете?
Нужно еще с заказчиком пообщаться. Договора оформить. Проект сдать. Деньги получить?
Таким методом, вы можете работать силами одного программиста. В общем как — то так выходит.
Обычно я придерживаюсь следующих норм времени:
1) 25% на постановку задачи;
2) 50% на проектирование;
3) 15% на кодирование;
4) 10% на тестирование.
Применительно к вашему случаю, вы взяли на себя выполнение пункта 1 и 2, то есть 70% работы и заложились в 8 часов
Кодеру дали возможность 15 часов делать 15% от общего объема работ. В шею такого кодера!
Если он не сделает работу за 2 часа — с вещами на выход!
Сообщение №4
Что делать? Действительно, как уже высказались Tango и DitriX нанимаем нормального программиста к себе в офис, что бы был всегда под рукой.
PMBOK4 сжигаем на костре. Вместо нее берем за основу берем методику Agile.
Напиваемся в усьмерть с новым программистом. Одно из двух: либо вы столкнетесь с неразрешимыми противоречиями,
либо перейдете на другой уровень общения и взаимопонимания.
Сообщение №6
Исходя из выше изложенного я бы по пунктам вашего кейса поступил бы следующим образом:
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) — Забить!!! Это от лукавого, по крайней мере в данном случае.
Сообщение №7
Приношу извинения за резкий тон. Просто хотелось бы кратко и по существу. Ваша статья несет большую полезную нагрузку и для новичков и для профессионалов.
Респект Вам и Уважуха. С удовольствием читаю ваши статьи. Просто в данном случае у нас с вами слишком большая разница в подходах. Надеюсь до холиварщины не дойдет.
(6)q_i, Спасибо. Вывод: проверять любой документ через правописание. ))
(7)tango, Согласен. Однако отмечу, что данный подход незаменим при работе с программистами-фрилансерами. Примерное соотношение времени 1 к 3. Т.е. лучше я затрачу время на формализацию задачи, а исполнение, тестирование и отладка ляжет на другом специалисте. Разделение труда, понимаешь.
(8) DitriX, Вот об чём и речь, что либо ты тратишь время на устные разъяснения либо формализацию своего видения. Вариант «он сам придумает как сделать» — не проходит. Слишком широкие рамки. Данный подход использую только с теми программистами, с кем уже давно работаешь, я знаю, что он может, он знает как работать со мной.
С новыми программистами, удаленщиками и фрилансерами — подробная формализация.
(9) Evgen.Ponomarenko, Передайте ему от меня пожелание удачи
Да уж..
Заместо того, чтобы написать всё самому за пару часов, нужно оказывается, 8 часов на описание хотелки и 15 часов на исполнение.
п..ц
Почему бы еще штат сотрудников человек в 100 не привлечь ?
:))
(11) Evgen.Ponomarenko, Я придерживаюсь соотношения 1 к 3. или 30% времени на анализ и формализацию задачи, остальное на разработку, тестирование, отладку, внедрение. Время на договора, сбор информации отдельная песня. Об этом у меня есть отдельный кейс «Производственное предприятие. Экспресс обследование»
В остальном согласен, проектная группа состоит примерно из 4-х человек: РП, архитектор, консультант, программист. Этого достаточно, чтобы поднимать проекты с годовой выручкой около 40 млн.
Если проект меньше, то функции РП и Архитектора объединяем.
Если еще меньше, то консультант идет в сад. функция ложится на РП
(13) Evgen.Ponomarenko, Это время не фактической работы, а время, которое будет оплачено. Если Вы сделали задачу за 1 час вместо 16, то Вы молодцы — получите зарплату как за 16, а если вместо 16 часов потратили 30 часов — что ж, все когда-то учились, Вам будет оплачено только 16.
(20) Ёпрст, Если бы все было бы так просто, то эта организация, для которой решалась данная проблема, не мучилась бы 2 года. А так согласен, самому действительно можно сделать, особенно когда задание уже кем-то формализовано.
К сожалению, когда у Вас параллельно идет несколько проектов, то приходится передавать часть своих умений на сторону. А чтоб не получить в обратку поток кучи вопросов — делаю формализацию.
Т.О. при определенной сноровке, один день формализации загружает примерно двух программистов в течении 3-4-х дней. Соответственно неделя формализации даёт месячную загрузку проектной команды. Плюс появляется инструмент для контроля выполнения.
(21)
Согласен, соотношение — не догма. В реальной жизни 1 к 3 и получается 😉
По поводу проектной группы с выручкой в 40 млн, то же согласен.
Хотя и контекста статьи вытекало, что их всего двое: РП+Программист.
В случае с УПП добавил бы еще одного программиста, уж больно УПП неворотлива.
А то Пользователей жалко и Консультанта — в рукопашную до ночи данные калашматить.
А но то прикольно получается, смотреть как люди на износ работают…
Мне нравится, когда проект в срок сдается, и люди вовремя домой уходят.
(21)
Любопытно было бы взлянуть, вот ни разу Экспресс обследование не давало реальной картины.
Пока три месяца на предприятии не поваришься — границы проекта размыты до нельзя.
Так, что если не коммерческая тайна — выкладывайте, будет интересно!
(25) Evgen.Ponomarenko,
(22)
нееее… ну это меняет дело, просто из статьи это не вытекает. Вы многие моменты пропустили. В таком случае в разделе «Норматив времени нужно было указать не 15, а допустим 4». Разницу программисту выдать в конце месяца в виде премии ;)))
(26)
ага, СПС… видел… отметился ещё 01.09.13. На досуге перечитаю 😉
(18) не соглашусь, это тоже самое, что нанять на работу водителя и начинать ему разъяснять на какую педаль жать,когда включать поворот и каким маршрутом ехать.
Если вы нанимаете программиста, то вы ему должны изложить суть, он сам найдет подход.
А что толку, вы дали ему чуткое руководство к действию, он без понимания — тупо это делает, а потом будет пытаться туда что то навязать.
Самое веселое — если вы в таком подробном ТЗ допустили ошибку. Вот это весело будет. Кто тогда виноват?
Но а если мы говорим про студента, то тогда так и статью назовите «Руководство действия для чайника».
Везде есть риски, водитель тоже может быть профи, но в итоге врезаться во что то или опоздать на какое то время к пункту прибытия.
(29) DitriX, Причем тут водитель. Есть два подхода:
1) дать подробную инструкцию
2) дать задание и ждать решение.
Вопрос: Какой из двух подходов предпочтительней?
Нет ответа — зависит от специфики проекта, привлекаемых ресурсов, личных навыков
Если нет знаний на уровне платформы, сам никогда код не писал, то тогда конечно второй подход. А если твой опыт достаточен для проектирования систем — тогда первый. Для этого и вводится позиция Архитектора. Нет у меня времени на пальцах объяснять очевидные мне вещи программисту — я хочу получить результат в нужные мне сроки. Я отвечаю за функциональность системы. Не программист. Он в офисе сидит, я у клиента систему сдаю. Нужны мне неожиданности?
Другая ситуация — мне дали программиста. Ок, отлично, только мне нужно выполнить работы в рамках производственного контура, а он последние 3 года автоматизировал только магазины. Вопрос, надо ли давать ему возможность самому придумывать решение. Однозначно Нет — у него недостаточно опыта в предметной области.
И еще момент: в каждой ИТ компании недостаток специалистов. В каждой. Никаких предпосылок, что проблема в ближайшие годы будет решена нет.
С другой стороны есть армия программистов, которые сидят на своем месте, получают зарплату, загрузка у них не очень большая и они вполне могут взять халтуру. Чтобы использовать данный ресурс, надо точно формулировать задачу.
(30)
это про меня, поэтому мои две: мне надо объяснить «зачем», какую проблему пользователя решаем
(31) tango, Обязательно словами? Вроде описание проблемы есть в «Задании на разработку»
Из списка показанных документов на практике обязательно только подробное задание словами заказчика, формализация задачи в понимании разработчика и описание действий пользователя с контрольным примером. Остальное только для тех, кто знает структуру конфигурации, особенности платформы и имеет навыки программирования. Но здесь есть две вещи, которые являются препятствием. 1.Не все постановщики обладают необходимыми знаниями, чтобы так подробно расписать предстоящее задание. 2.Не дай бог, чтобы у программиста в начальниках будет бывший программист. Замучает куда и как кодировать. ИМХО, разработчик должен сам решать как и что программировать. Достаточно этап планирования изменений в конфигурации держать под контролем и согласованием. В целом статья неплохая. Успехов автору.
(32) можно в танце, но вечером
я к тому, что остальное — не обязательно
**
учитывая справедливое (иногда) — замучает — предыдущего оратора, иногда даже и вредно
(в таких случаях хочется сказать — если ты такой умный — сделай это уже)
Хорошо расписано, сталкивался с подобным в бытность работы в ИВЦ «Мосстрой».
Сохраняю в избранное, беру на вооружение.
все по делу написано, блин ну почему же на этом сайте нет раздела кейсы ( а то потом искать как всегда, когда нужно не найдешь… пс: в вашей ситуации когда работает аутсорсер или свой большой штат программистов, есть аналитики, методисты и тд.. тогда да, чем подробнее тем лучше, только грамотных постановщиков запаришься искать. А для отдела с 1-5 программистами помоему такое излишне…
PS: пошел на форум писать про то чтобы добавили раздел кейсы, а то доминикану добавили, кейсы то нужнее в разы чем фото с тая )
У меня был опыт довольно плодотворной работы с одним постановщиком задач (он же соучередитель бизнеса), который вообще не работал в 1С (при этом 1С УТ 10.2 — основная учетная система в компании и все ее доработки ставил он, УТ по объему логики не уступает УПП). При постановке задачи он оперировал следующими терминами:
1. Таблица — некая логическая табличная сущность;
2. Документ — под этим он понимал печатную форму какого либо документа (ТОРГ 12, СФ и пр.), причем если печатных форм несколько, то это для него было несколько документов.
3. Отчет — здесь очень близко к реальности — отчет с настройками и неким результатом.
И это по большому счету все!
По началу я пытался его обучить использовать терминологию 1С, чему он не возражал в общем, но продолжал использовать исключительно свою терминологию.
В результате, по степени проработки деталей, объему логики, удобству и стабильности работы это до сих пор не превзойденная конфигурация из тех, что я видел.
Вобщем есть форма, а есть содержание…
(30)Согласен. (29) Не согласен.
ИМХО, такая метода постановки задач не всегда оправдана (даже наверное в половине случаев). Для новых клиентов, особенно когда нужны не доработки, а именно внедрение 1С, тогда согласен на все 100%.
Но для приведенного примера, по небольшой задачке на доработку тратить 8 часов на постановку задачи…
Это уж черезчур, опять-таки, ИМХО. Особенно если программист «СВОЙ». Если есть риск оппортунизма со стороны «внешних» программистов, то как средство защиты и минимизации рисков прокатит… Хотя, опять-таки, если на Вас работает команда фрилансеров-однозадачников (не длительное сотрудничество), то какая разница? Не сделали так как нужно было — не получили ЗП (конечно, в таком случае возникает проблема срыва сроков, но опять-таки, экономится время на постановку задачи… и, за что всегда ратую: КЛИЕНТУ ЗАЧАСТУЮ ПЛЕВАТЬ НА СРОКИ — так почему бы не назвать «с запасом»? Задачка на 1 день — называем 2-3 дня и имеем гарантию от «криворукости» фрилансера).
(37) Tsaregorodtsev,
ой. я что-то пропустил?
(37) Tsaregorodtsev,
2. Документ — под этим он понимал печатную форму какого либо документа (ТОРГ 12, СФ и пр.), причем если печатных форм несколько, то это для него было несколько документов.
3. Отчет — здесь очень близко к реальности — отчет с настройками и неким результатом.
И это по большому счету все!
это — да. в таком объеме юзерские сущности и имеют место быть. упорным трудом удается внедрить в ихнее сознание понятие «диалог» как экранной формы
(40) tango,
— это значит очень сильно доработанная УТ, не более того.
(30) ну может быть. Вам виднее, я то смотрю со стороны программиста 🙂
(43) DitriX,
Мне за свою бытность довелось:
1) Набраться опыта работая программистом на заводе
2) 5 лет руководить внедрением и разработкой ERP системы «Финансовая коллекция» на базе Oracle (сейчас используются в 5-ти энергетических компаниях Украины)
3) 5 лет сопровождать этот продукт в Харьковоблэнерго в качестве руководителя секторов «Бухгалтерских задач» и «Администрирования БД Oracle»
4) 4 года
Внедрять УПП, УТП. Руководить разработкой и продвижением сайтов.
5) 4 года разрабатываю и внедряю собственную конфигурацию.
За это время прошел стадии:
Программиста,
Руководителя проектами,
Архитектора
Консультанта
Web-разработчика
Собственника
Бизнес-аналитика
И снова Программиста.
И со всей ответственностью заявляю — Вы чертовски ПРАВЫ! Просто не успел Вас плюсануть ;)))
Со стороны программиста Ваш взгляд на руководителя, с моей точки зрения вполне адекватный.
Между нами кроликами, я сам чуть не напросился к verter.me пофрилансить )))))))) см (30)
Верьте только себе и своему опыту.
2) дать задание и ждать решение.
Нет черного и белого. Есть множество Вариантов между п1 и п2, некоторые из них подходят лично Вам.
(30)verter.me,
Андрей. У Вас сильная Харизма, у Вас Великий Дар — убеждать. Ради бога — поосторожнее…
(44) вот блин, а я напросился к нему, но меня проигнорировали.Почему? Ну тут уже нюансы 🙂
Кроме этого — я прошел через часть этих стадий, в частности от программиста, до руководителя, далее собственника, а теперь работаю с напарниками в нами же созданной фирме — обычными программистами 🙂
Коллеги, только без обид.
Не готов я пока выступать в качестве работодателя.
Чуть позже.
(47) ничего страшного, просто вы сами на конференции предложили работу.
Мне стало интересно, не сколько даже ради денег, а идея понравилась. Я может бы даже бесплатно работал, денег мне и так, как бы, хватает.
А вы вместо того, что бы просто сказать что-то типо «извини, давай может через годик свяжемся?», просто оборвали беседу. Я не в обиде, но ваш поступок, на фоне ваших статей, был для меня шоком. 🙂
(44) Evgen.Ponomarenko,
таки в первых обстоятельства довлеют
личностные качества либо адекватны, либо нет
ну, т.е. под 1снега, РП ли, кодера ли, мир прогибаться не будет
да и макаревич скорее пассивен в результате 🙂
пс: (50) — прекрасная иллюстрация
(48) DitriX,
просто в рамочку
(48) DitriX, Как оказалось, предложить было намного проще, чем обеспечить.
Было допущено несколько серьезных проколов. Надо было решить важную задачу — обеспечить текущий доход. Чуть было даже не пошел работать по найму.
Морально сильно просел. На проект смотреть не мог, не то что сотрудничать с кем-то.
Проект был почти на грани закрытия. Даже статьи писать не мог.
Парадокс в том, что чужой бизнес оптимизировать намного проще, чем строить свой. Даже имея необходимые знания.
Сейчас всё налаживается
(50)verter.me, спасибо за кейс и удачи в бизнесе!
Тоже с удовольствием прочел все статьи и что-то для себя в них увидел.
Как периодически фрилансящий фикси хочу сказать, что грамотная (как в статье) постановка задачи — это огромный плюс. Такое встречается очень редко. Обычно привыкаешь догадываться за постоянного клиента, что он имеет в виду. Но по-первости тратишь кучу своего времени на переделки.
А что программисту тогда делать ??????
Нет тут не программист нужен а тупо кодер!!
Автору спасибо
Такой подход может обеспечить качество. Но такая постановка отнимает много времени. Каким количеством программистов Вам удается руководить, используя такую методику?
(53) bsuray, Хороший вопрос, Богдан!
Не знаю, не проверял. Данную методику только только оформил в готовом виде. До этого делал как всегда: устно ставил задачи, что-то писал, что-то рисовал. А вот теперь понадобилась.
Какое количество программистов? Давайте прикинем
Итак: для оформления одного задания нужно 8 часов или 1 рабочий день. Одно задание для 1 программиста. Одно задание ему на 24 часа, т.е. 3 рабочих дня. Я взял соотношение 1 к 3.
Т.О. за 5 дней можно подготовить 5 заданий и загрузить программиста на 15 рабочих дней. Плюс 5 дней на тестирование. Получается полный месяц.
Если брать полный месяц под формализацию, то можно загрузить до 4 программистов. Наверное.
Делаем вывод: Работа одного специалиста по формализации задач (консультант? архитектор?), может дать работу 4 программистам. Если учесть выходные, то можно и 5-го впихнуть.
Похоже на правду 🙂
Год назад мне дали полдесятка необученных программистов. Чтоб избежать сюрпризов и не переделывать все самому в последний момент, решил применять подобный подход. Столкнулся с такими трудностями:
— Случалось, что ребята делали работу быстрее чем я успевали успевал ставить задачи.
— Если была работа, которую не мог поручить другим, то методика рушилась. Ребята или простаивали или приходилось довериться им и периодически давать им подсказки.
— При 4-х программистах консультант должен быть хорошего уровня. Иначе нужно его подстраховывать и снова методика рушится.
Пришел к выводу, что в команде программистов должен быть хотя бы один человек, в чьей квалификации я полностью уверен и кому могу доверить часть разработки.
Методика полезная. Брать ее на вооружение стоит. Все-таки качество лучше начинать контролировать на входе, а не выходе. И стоит понимать, что может помешать применению этой методики.
(55) bsuray, Согласен, простой программистов из-за отсутствия постановки задачи — это проблема. Одно из решений — не иметь под собой вообще программистов. Будет необходимость, формализовали задачу. При наличии готовых заданий на разработку, найти исполнителя вполне реально.
Подскажите, каким редактором пользуетесь при создании Кейсов? И чем рисуете блок-схемы?
(58) McCoy77, схемы рисую с помощью MS Visio, сам документ делаю в Pages при необходимости выгружаю из него в Word (но это редко, в основном выгружаю в PDF, он тогда красивый получается)