Кейс "Задание на разработку"

Рассмотрим ситуацию постановки задачи СВОЕМУ программисту. Т.е. пишем техническое задание не для клиента, а своему, такому же раздолбаю, который сидит в соседнем отделе и носит гордое имя "программист". Ах, у Вас он даже в офис не ходит? Дома работает? Что ж, скайп нам в руки. А у Вас? Вы вообще его лично никогда не видели? Значит ситуация сложнее.
И ведь он, поганец такой, требует, чтоб ему дали конкретную работу. И не грузили всякой ерундой и не лили воду на мельницу.
В идеале, было бы вообще замечательно, если бы можно было бы из технического задания, которое мы подготовили для клиента, нарезать небольшие задания и раздавать их разным исполнителям. А затем в проджекте галочки об исполнении ставить.

Но ведь нет, на практике же приходится давать устные пояснения по каждому пункту. Объяснять, что имелось в виду вот в этом предложении ТЗ в тот момент, когда его формулировал для клиента.

Вот и предлагаю способ сохранить нервы себе и уверенность в Вас со стороны программиста.  

Первый лист — титульный. Никаких строк согласования не требуется. Достаточно приведенных параметров. Можно еще какую-нибудь картинку для красоты добавить.

Далее, история изменений. Мы ведь тоже не идеальны и с первого раза можем ТЗ только клиенту сдать. А наш коллега всегда найдёт в чём мы не правы. Ему же делать. Так что сразу планируйте минимум 3 итерации. Или 3 версии. И еще, желательно в колонке «состав изменений» писать понятно. Можно подробно. 

Теперь обозначаем главную проблему, делаем привязку к срокам, платформе, конфигурации, режиму работы. Связанным задачам, которые нужно решить в рамках данного задания

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

Здесь чистая литература. Как получится. Желательно выявить не только проблему, но и причины ее появления.

Входите в режим «бога» и предлагаете РЕШЕНИЕ. Возможно даже правильное. 

Это вообще бесподобно. Вы предлагаете не только решение, но и способ как его реализовать. Но особо не настаивайте, можно придумать его вместе с программистом. Ему приятно, да и Вам попрактиковаться в командообразовании надо. 

Показываем кто в доме хозяин и почему именно Вы занимаете эту должность. Лишний раз продемонстрировать Ваши навыки совсем не помешает. Смысл, правда, тоже желательно чтобы был. Про логику напоминать надо? 

Да, да. Вы, как бы, влезаете в шкуру конечного пользователя и пытаетесь мысленно продумать последовательно шагов. Сложно? Посмотрите фильм «Бойцовский клуб» или «Плутовство или хвост виляет собакой». В этот момент надо представить конкретного человека на стороне заказчика, который будет работать с Вашим РЕШЕНИЕМ. Ощутили его эмоции? Не стыдно? Тогда вперед.

Закончили с прелюдией. Теперь переходим к конкретике. Делаем карточку с общей информацией для каждого связанного задания. Учитываем особенность. Что это? Регистр сведений, накопления, обработка, отчет, документ, справочник? от этого будет зависеть структура параметров в карточке.

Теперь описываем структуру данного объекта. Побольше уверенности. Если что, Вам непременно укажут на Ваши ошибки, и вы сделаете новую версию задания.

Если в задании несколько сквозных задач — описываем каждое из них отдельно. Сначала карточку с общей информацией

Затем структуру. Вспоминаем фильм. «В себя веришь? Верю. Цель видишь? Вижу»

Задание предполагает интерфейс пользователя. Что ж, значит надо заняться прототипированием. В первой версии задания, достаточно использовать скан обычного листа бумаги с Вашим творчеством. В последующих версиях заменить рисунки на скрин-шоты реальных форм. Опять таки — думаем о пользователе!!! Ему работать!

Я делаю примерно так:

1. Сначала рисую интерфейс на бумаге А4 в разных вариантах. Выбираю подходящий

2. Делаю в конфигураторе форму без обработчиков событий. Типа скелет. Затем отсылаю задание и скелет обработки программисту. Он наполняет ее смыслом, кодом, матюгами.

3. Я тестирую и вставляю программисту за невнимательность. Иногда всё работает с первого раза.

Интерфейс можно условно разделить на блоки. Какие? обозначьте их. Опишите их

Далее, каждый блок расписываем подробненько по функциям. 

И так для каждого блока

Если задача предполагает заполнение некой третьей формы со своими реквизитами — сделайте табличку по правилам заполнения каждого нужного реквизита. Реквизиты которые не заполняются и не влияют на работоспособность формы не указываем. Помним — воду не льем.

То же самое делаем для реквизитов табличных частей, если они имеются.

 В принципе, этого достаточно. Но можно дополнить задание космосом:

добавить сценарии тестирования

показатели успешности (KPI) — чтобы оценить насколько улучшилась работа заказчика. Сколько он сэкономил, насколько увеличилась его производительность и упала трудоёмкость.

Сколько времени надо на формулировку одного задания? 8 часов. 1 рабочий день и одна ночь, вдруг какие умные мысли придут. Если опыта мало умножайте на 3.

Приложение: файл «Задание на разработку.pdf»

p.s.: присоединяйтесь к группе «Записки внедренца 1С» тут 

58 Comments

  1. Evgen.Ponomarenko

    Все замечельно, ясно и понятно. Вот только можно два вопроса?

    1) «СВОЕМУ» — что Вы вкладываете в это понятие?

    2) Для кого написана эта статья?

    Reply
  2. verter.me

    1) СВОЙ программист, это специалист, которому Вы ставите задачу. Т. Е. Вы постановщик задач, исполняют их другие люди. Иногда они находятся на удалённой работе. Но так или иначе они получают от Вас зарплату и отвечают за исполнение поставленных им задач.

    2) для консультантов, архитекторов, руководителей проектов. Зависит от разделения функций на проекте.

    Reply
  3. AnryMc

    Это не «кейс», а наглядный пример…

    Reply
  4. verter.me

    (3) AnryMc, Пусть будет так. Словом «кейс», я обозначаю статьи, материал которых можно использовать в своей деятельности, без лишней заумности.

    Точно так же и в Вашей компании — Вам дают образец или последний хороший документ, который готовили и «делай как тут».

    Reply
  5. Algiz

    Спасибо, возьмем на заметку

    Reply
  6. q_i

    Небольшое замечание по скриншотам:

    Описание проблемной области

    …много времени тратит(без Ь)ся…

    Решение

    …тем быстрее документ будет проводит(с Ь)ся…

    Reply
  7. tango

    Все красиво. Маленькая грабля: детализируя тз кодеру до такой степени, автор практически выполнил разработку. Заполнить нужные места нужным кодом — времени уйдет на порядок меньше, чем передавать эту детализацию кодеру (а потом еще и принимать обратно, и не факт — что кодер при этом заполнит нужные места нужным кодом).

    Reply
  8. DitriX

    (7) полностью согласен.

    (0) Если у вас на фирме кодер — гоните в шею и наймите программиста.

    Программист сам будет знать какой регистр сведений надо создать и с какими реквизитами, а отчет об новых объектах — это отчет из хранилища.

    Программистам должна ставиться не задача, как таковая, а разъяснение того, что вы хотите получить в конце. А он сам придумает как сделать.

    Reply
  9. Evgen.Ponomarenko

    Сообщение №1

    За статью спасибо. Выслал её «СВОЕМУ» бывшему программисту как шаблон.

    У него сегодня в конце дня дебют: встреча с реальным заказчиком один на один.

    Передает Вам свою благодарность.

    Reply
  10. Evgen.Ponomarenko

    Сообщение №2

    По поводу раздолбая и поганца. Статья хорошая, а вот соус под которым она подана — не очень.

    Давайте относиться друг к другу с Уважением, стоить схему отношений не Руководитель vs Программист, а

    Руководитель & Программист. Даже, если парень «раздолбай», объясните ему, что его легкомысленное отношение,

    дает возможность заказчику повесить на него всех собак.

    Что в этом случае он будет, как минимум работать и выгребать за троих: за себя, за вас и за заказчика, а получит зп только за себя,если конечно проект будет сдан во время и в рамках бюджета.

    Надеюсь аннотация к статье скорее результат куража после дня программиста, а не устойчивая и осознанная позиция Руководителя.

    Reply
  11. Evgen.Ponomarenko

    Сообщение №3

    Анализ эффективности применения данного подхода:

    С ваших слов, затратив 8 часов времени своего времени, вы определяете фронт работ программисту на 15 часов.

    Таким образом, в лучшем случае вы можете управлять 2-мя программистами. А пользу вы когда приносить будете?

    Нужно еще с заказчиком пообщаться. Договора оформить. Проект сдать. Деньги получить?

    Таким методом, вы можете работать силами одного программиста. В общем как — то так выходит.

    Обычно я придерживаюсь следующих норм времени:

    1) 25% на постановку задачи;

    2) 50% на проектирование;

    3) 15% на кодирование;

    4) 10% на тестирование.

    Применительно к вашему случаю, вы взяли на себя выполнение пункта 1 и 2, то есть 70% работы и заложились в 8 часов

    Кодеру дали возможность 15 часов делать 15% от общего объема работ. В шею такого кодера!

    Если он не сделает работу за 2 часа — с вещами на выход!

    Reply
  12. Evgen.Ponomarenko

    Сообщение №4

    Что делать? Действительно, как уже высказались Tango и DitriX нанимаем нормального программиста к себе в офис, что бы был всегда под рукой.

    PMBOK4 сжигаем на костре. Вместо нее берем за основу берем методику Agile.

    Напиваемся в усьмерть с новым программистом. Одно из двух: либо вы столкнетесь с неразрешимыми противоречиями,

    либо перейдете на другой уровень общения и взаимопонимания.

    Reply
  13. Evgen.Ponomarenko

    Сообщение №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) — Забить!!! Это от лукавого, по крайней мере в данном случае.

    Reply
  14. Evgen.Ponomarenko

    Сообщение №7

    Приношу извинения за резкий тон. Просто хотелось бы кратко и по существу. Ваша статья несет большую полезную нагрузку и для новичков и для профессионалов.

    Респект Вам и Уважуха. С удовольствием читаю ваши статьи. Просто в данном случае у нас с вами слишком большая разница в подходах. Надеюсь до холиварщины не дойдет.

    Reply
  15. verter.me

    (6)q_i, Спасибо. Вывод: проверять любой документ через правописание. ))

    Reply
  16. verter.me

    (7)tango, Согласен. Однако отмечу, что данный подход незаменим при работе с программистами-фрилансерами. Примерное соотношение времени 1 к 3. Т.е. лучше я затрачу время на формализацию задачи, а исполнение, тестирование и отладка ляжет на другом специалисте. Разделение труда, понимаешь.

    Reply
  17. verter.me

    (8) DitriX, Вот об чём и речь, что либо ты тратишь время на устные разъяснения либо формализацию своего видения. Вариант «он сам придумает как сделать» — не проходит. Слишком широкие рамки. Данный подход использую только с теми программистами, с кем уже давно работаешь, я знаю, что он может, он знает как работать со мной.

    С новыми программистами, удаленщиками и фрилансерами — подробная формализация.

    Reply
  18. verter.me

    (9) Evgen.Ponomarenko, Передайте ему от меня пожелание удачи

    Reply
  19. Ёпрст

    Да уж..

    Заместо того, чтобы написать всё самому за пару часов, нужно оказывается, 8 часов на описание хотелки и 15 часов на исполнение.

    п..ц

    Почему бы еще штат сотрудников человек в 100 не привлечь ?

    :))

    Reply
  20. verter.me

    (11) Evgen.Ponomarenko, Я придерживаюсь соотношения 1 к 3. или 30% времени на анализ и формализацию задачи, остальное на разработку, тестирование, отладку, внедрение. Время на договора, сбор информации отдельная песня. Об этом у меня есть отдельный кейс «Производственное предприятие. Экспресс обследование»

    В остальном согласен, проектная группа состоит примерно из 4-х человек: РП, архитектор, консультант, программист. Этого достаточно, чтобы поднимать проекты с годовой выручкой около 40 млн.

    Если проект меньше, то функции РП и Архитектора объединяем.

    Если еще меньше, то консультант идет в сад. функция ложится на РП

    Reply
  21. verter.me

    (13) Evgen.Ponomarenko, Это время не фактической работы, а время, которое будет оплачено. Если Вы сделали задачу за 1 час вместо 16, то Вы молодцы — получите зарплату как за 16, а если вместо 16 часов потратили 30 часов — что ж, все когда-то учились, Вам будет оплачено только 16.

    Reply
  22. verter.me

    (20) Ёпрст, Если бы все было бы так просто, то эта организация, для которой решалась данная проблема, не мучилась бы 2 года. А так согласен, самому действительно можно сделать, особенно когда задание уже кем-то формализовано.

    К сожалению, когда у Вас параллельно идет несколько проектов, то приходится передавать часть своих умений на сторону. А чтоб не получить в обратку поток кучи вопросов — делаю формализацию.

    Т.О. при определенной сноровке, один день формализации загружает примерно двух программистов в течении 3-4-х дней. Соответственно неделя формализации даёт месячную загрузку проектной команды. Плюс появляется инструмент для контроля выполнения.

    Reply
  23. Evgen.Ponomarenko

    (21)

    Согласен, соотношение — не догма. В реальной жизни 1 к 3 и получается 😉

    По поводу проектной группы с выручкой в 40 млн, то же согласен.

    Хотя и контекста статьи вытекало, что их всего двое: РП+Программист.

    В случае с УПП добавил бы еще одного программиста, уж больно УПП неворотлива.

    А то Пользователей жалко и Консультанта — в рукопашную до ночи данные калашматить.

    А но то прикольно получается, смотреть как люди на износ работают…

    Мне нравится, когда проект в срок сдается, и люди вовремя домой уходят.

    Reply
  24. Evgen.Ponomarenko

    (21)

    Об этом у меня есть отдельный кейс «Производственное предприятие. Экспресс обследование»

    Любопытно было бы взлянуть, вот ни разу Экспресс обследование не давало реальной картины.

    Пока три месяца на предприятии не поваришься — границы проекта размыты до нельзя.

    Так, что если не коммерческая тайна — выкладывайте, будет интересно!

    Reply
  25. verter.me

    (25) Evgen.Ponomarenko, http://infostart.ru/public/189271/

    Reply
  26. Evgen.Ponomarenko

    (22)

    нееее… ну это меняет дело, просто из статьи это не вытекает. Вы многие моменты пропустили. В таком случае в разделе «Норматив времени нужно было указать не 15, а допустим 4». Разницу программисту выдать в конце месяца в виде премии ;)))

    Reply
  27. Evgen.Ponomarenko

    (26)

    ага, СПС… видел… отметился ещё 01.09.13. На досуге перечитаю 😉

    Reply
  28. DitriX

    (18) не соглашусь, это тоже самое, что нанять на работу водителя и начинать ему разъяснять на какую педаль жать,когда включать поворот и каким маршрутом ехать.

    Если вы нанимаете программиста, то вы ему должны изложить суть, он сам найдет подход.

    А что толку, вы дали ему чуткое руководство к действию, он без понимания — тупо это делает, а потом будет пытаться туда что то навязать.

    Самое веселое — если вы в таком подробном ТЗ допустили ошибку. Вот это весело будет. Кто тогда виноват?

    Но а если мы говорим про студента, то тогда так и статью назовите «Руководство действия для чайника».

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

    Reply
  29. verter.me

    (29) DitriX, Причем тут водитель. Есть два подхода:

    1) дать подробную инструкцию

    2) дать задание и ждать решение.

    Вопрос: Какой из двух подходов предпочтительней?

    Нет ответа — зависит от специфики проекта, привлекаемых ресурсов, личных навыков

    Если нет знаний на уровне платформы, сам никогда код не писал, то тогда конечно второй подход. А если твой опыт достаточен для проектирования систем — тогда первый. Для этого и вводится позиция Архитектора. Нет у меня времени на пальцах объяснять очевидные мне вещи программисту — я хочу получить результат в нужные мне сроки. Я отвечаю за функциональность системы. Не программист. Он в офисе сидит, я у клиента систему сдаю. Нужны мне неожиданности?

    Другая ситуация — мне дали программиста. Ок, отлично, только мне нужно выполнить работы в рамках производственного контура, а он последние 3 года автоматизировал только магазины. Вопрос, надо ли давать ему возможность самому придумывать решение. Однозначно Нет — у него недостаточно опыта в предметной области.

    И еще момент: в каждой ИТ компании недостаток специалистов. В каждой. Никаких предпосылок, что проблема в ближайшие годы будет решена нет.

    С другой стороны есть армия программистов, которые сидят на своем месте, получают зарплату, загрузка у них не очень большая и они вполне могут взять халтуру. Чтобы использовать данный ресурс, надо точно формулировать задачу.

    Reply
  30. tango

    (30)

    С другой стороны есть армия программистов, которые сидят на своем месте, получают зарплату, загрузка у них не очень большая и они вполне могут взять халтуру. Чтобы использовать данный ресурс, надо точно формулировать задачу.

    это про меня, поэтому мои две: мне надо объяснить «зачем», какую проблему пользователя решаем

    Reply
  31. verter.me

    (31) tango, Обязательно словами? Вроде описание проблемы есть в «Задании на разработку»

    Reply
  32. МимохожийОднако

    Из списка показанных документов на практике обязательно только подробное задание словами заказчика, формализация задачи в понимании разработчика и описание действий пользователя с контрольным примером. Остальное только для тех, кто знает структуру конфигурации, особенности платформы и имеет навыки программирования. Но здесь есть две вещи, которые являются препятствием. 1.Не все постановщики обладают необходимыми знаниями, чтобы так подробно расписать предстоящее задание. 2.Не дай бог, чтобы у программиста в начальниках будет бывший программист. Замучает куда и как кодировать. ИМХО, разработчик должен сам решать как и что программировать. Достаточно этап планирования изменений в конфигурации держать под контролем и согласованием. В целом статья неплохая. Успехов автору.

    Reply
  33. tango

    (32) можно в танце, но вечером

    я к тому, что остальное — не обязательно

    **

    учитывая справедливое (иногда) — замучает — предыдущего оратора, иногда даже и вредно

    (в таких случаях хочется сказать — если ты такой умный — сделай это уже)

    Reply
  34. Sintson

    Хорошо расписано, сталкивался с подобным в бытность работы в ИВЦ «Мосстрой».

    Сохраняю в избранное, беру на вооружение.

    Reply
  35. AllexSoft

    все по делу написано, блин ну почему же на этом сайте нет раздела кейсы ( а то потом искать как всегда, когда нужно не найдешь… пс: в вашей ситуации когда работает аутсорсер или свой большой штат программистов, есть аналитики, методисты и тд.. тогда да, чем подробнее тем лучше, только грамотных постановщиков запаришься искать. А для отдела с 1-5 программистами помоему такое излишне…

    PS: пошел на форум писать про то чтобы добавили раздел кейсы, а то доминикану добавили, кейсы то нужнее в разы чем фото с тая )

    Reply
  36. TSSV

    У меня был опыт довольно плодотворной работы с одним постановщиком задач (он же соучередитель бизнеса), который вообще не работал в 1С (при этом 1С УТ 10.2 — основная учетная система в компании и все ее доработки ставил он, УТ по объему логики не уступает УПП). При постановке задачи он оперировал следующими терминами:

    1. Таблица — некая логическая табличная сущность;

    2. Документ — под этим он понимал печатную форму какого либо документа (ТОРГ 12, СФ и пр.), причем если печатных форм несколько, то это для него было несколько документов.

    3. Отчет — здесь очень близко к реальности — отчет с настройками и неким результатом.

    И это по большому счету все!

    По началу я пытался его обучить использовать терминологию 1С, чему он не возражал в общем, но продолжал использовать исключительно свою терминологию.

    В результате, по степени проработки деталей, объему логики, удобству и стабильности работы это до сих пор не превзойденная конфигурация из тех, что я видел.

    Вобщем есть форма, а есть содержание…

    Reply
  37. Ish_2

    (30)Согласен. (29) Не согласен.

    Reply
  38. BudkoT

    ИМХО, такая метода постановки задач не всегда оправдана (даже наверное в половине случаев). Для новых клиентов, особенно когда нужны не доработки, а именно внедрение 1С, тогда согласен на все 100%.

    Но для приведенного примера, по небольшой задачке на доработку тратить 8 часов на постановку задачи…

    Это уж черезчур, опять-таки, ИМХО. Особенно если программист «СВОЙ». Если есть риск оппортунизма со стороны «внешних» программистов, то как средство защиты и минимизации рисков прокатит… Хотя, опять-таки, если на Вас работает команда фрилансеров-однозадачников (не длительное сотрудничество), то какая разница? Не сделали так как нужно было — не получили ЗП (конечно, в таком случае возникает проблема срыва сроков, но опять-таки, экономится время на постановку задачи… и, за что всегда ратую: КЛИЕНТУ ЗАЧАСТУЮ ПЛЕВАТЬ НА СРОКИ — так почему бы не назвать «с запасом»? Задачка на 1 день — называем 2-3 дня и имеем гарантию от «криворукости» фрилансера).

    Reply
  39. tango

    (37) Tsaregorodtsev,

    УТ по объему логики не уступает УПП

    ой. я что-то пропустил?

    Reply
  40. tango

    (37) Tsaregorodtsev,

    1. Таблица — некая логическая табличная сущность;

    2. Документ — под этим он понимал печатную форму какого либо документа (ТОРГ 12, СФ и пр.), причем если печатных форм несколько, то это для него было несколько документов.

    3. Отчет — здесь очень близко к реальности — отчет с настройками и неким результатом.

    И это по большому счету все!

    это — да. в таком объеме юзерские сущности и имеют место быть. упорным трудом удается внедрить в ихнее сознание понятие «диалог» как экранной формы

    Reply
  41. TSSV

    (40) tango,

    УТ по объему логики не уступает УПП

    — это значит очень сильно доработанная УТ, не более того.

    Reply
  42. DitriX

    (30) ну может быть. Вам виднее, я то смотрю со стороны программиста 🙂

    Reply
  43. Evgen.Ponomarenko

    (43) DitriX,

    Мне за свою бытность довелось:

    1) Набраться опыта работая программистом на заводе

    2) 5 лет руководить внедрением и разработкой ERP системы «Финансовая коллекция» на базе Oracle (сейчас используются в 5-ти энергетических компаниях Украины)

    3) 5 лет сопровождать этот продукт в Харьковоблэнерго в качестве руководителя секторов «Бухгалтерских задач» и «Администрирования БД Oracle»

    4) 4 года

    Внедрять УПП, УТП. Руководить разработкой и продвижением сайтов.

    5) 4 года разрабатываю и внедряю собственную конфигурацию.

    За это время прошел стадии:

    Программиста,

    Руководителя проектами,

    Архитектора

    Консультанта

    Web-разработчика

    Собственника

    Бизнес-аналитика

    И снова Программиста.

    И со всей ответственностью заявляю — Вы чертовски ПРАВЫ! Просто не успел Вас плюсануть ;)))

    Со стороны программиста Ваш взгляд на руководителя, с моей точки зрения вполне адекватный.

    Между нами кроликами, я сам чуть не напросился к verter.me пофрилансить )))))))) см (30)

    Верьте только себе и своему опыту.

    1) дать подробную инструкцию

    2) дать задание и ждать решение.

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

    Reply
  44. Evgen.Ponomarenko

    (30)verter.me,

    Андрей. У Вас сильная Харизма, у Вас Великий Дар — убеждать. Ради бога — поосторожнее…

    Reply
  45. DitriX

    (44) вот блин, а я напросился к нему, но меня проигнорировали.Почему? Ну тут уже нюансы 🙂

    Кроме этого — я прошел через часть этих стадий, в частности от программиста, до руководителя, далее собственника, а теперь работаю с напарниками в нами же созданной фирме — обычными программистами 🙂

    Reply
  46. verter.me

    Коллеги, только без обид.

    Не готов я пока выступать в качестве работодателя.

    Чуть позже.

    Reply
  47. DitriX

    (47) ничего страшного, просто вы сами на конференции предложили работу.

    Мне стало интересно, не сколько даже ради денег, а идея понравилась. Я может бы даже бесплатно работал, денег мне и так, как бы, хватает.

    А вы вместо того, что бы просто сказать что-то типо «извини, давай может через годик свяжемся?», просто оборвали беседу. Я не в обиде, но ваш поступок, на фоне ваших статей, был для меня шоком. 🙂

    Reply
  48. tango

    (44) Evgen.Ponomarenko,

    некоторые из них подходят лично Вам.

    таки в первых обстоятельства довлеют

    личностные качества либо адекватны, либо нет

    ну, т.е. под 1снега, РП ли, кодера ли, мир прогибаться не будет

    да и макаревич скорее пассивен в результате 🙂

    пс: (50) — прекрасная иллюстрация

    (48) DitriX,

    Я может бы даже бесплатно работал

    просто в рамочку

    Reply
  49. verter.me

    (48) DitriX, Как оказалось, предложить было намного проще, чем обеспечить.

    Было допущено несколько серьезных проколов. Надо было решить важную задачу — обеспечить текущий доход. Чуть было даже не пошел работать по найму.

    Морально сильно просел. На проект смотреть не мог, не то что сотрудничать с кем-то.

    Проект был почти на грани закрытия. Даже статьи писать не мог.

    Парадокс в том, что чужой бизнес оптимизировать намного проще, чем строить свой. Даже имея необходимые знания.

    Сейчас всё налаживается

    Reply
  50. stanru1

    (50)verter.me, спасибо за кейс и удачи в бизнесе!

    Тоже с удовольствием прочел все статьи и что-то для себя в них увидел.

    Как периодически фрилансящий фикси хочу сказать, что грамотная (как в статье) постановка задачи — это огромный плюс. Такое встречается очень редко. Обычно привыкаешь догадываться за постоянного клиента, что он имеет в виду. Но по-первости тратишь кучу своего времени на переделки.

    Reply
  51. pro-rok

    А что программисту тогда делать ??????

    Нет тут не программист нужен а тупо кодер!!

    Автору спасибо

    Reply
  52. bsuray

    Такой подход может обеспечить качество. Но такая постановка отнимает много времени. Каким количеством программистов Вам удается руководить, используя такую методику?

    Reply
  53. verter.me

    (53) bsuray, Хороший вопрос, Богдан!

    Не знаю, не проверял. Данную методику только только оформил в готовом виде. До этого делал как всегда: устно ставил задачи, что-то писал, что-то рисовал. А вот теперь понадобилась.

    Какое количество программистов? Давайте прикинем

    Итак: для оформления одного задания нужно 8 часов или 1 рабочий день. Одно задание для 1 программиста. Одно задание ему на 24 часа, т.е. 3 рабочих дня. Я взял соотношение 1 к 3.

    Т.О. за 5 дней можно подготовить 5 заданий и загрузить программиста на 15 рабочих дней. Плюс 5 дней на тестирование. Получается полный месяц.

    Если брать полный месяц под формализацию, то можно загрузить до 4 программистов. Наверное.

    Делаем вывод: Работа одного специалиста по формализации задач (консультант? архитектор?), может дать работу 4 программистам. Если учесть выходные, то можно и 5-го впихнуть.

    Reply
  54. bsuray

    Похоже на правду 🙂

    Год назад мне дали полдесятка необученных программистов. Чтоб избежать сюрпризов и не переделывать все самому в последний момент, решил применять подобный подход. Столкнулся с такими трудностями:

    — Случалось, что ребята делали работу быстрее чем я успевали успевал ставить задачи.

    — Если была работа, которую не мог поручить другим, то методика рушилась. Ребята или простаивали или приходилось довериться им и периодически давать им подсказки.

    — При 4-х программистах консультант должен быть хорошего уровня. Иначе нужно его подстраховывать и снова методика рушится.

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

    Reply
  55. bsuray

    Методика полезная. Брать ее на вооружение стоит. Все-таки качество лучше начинать контролировать на входе, а не выходе. И стоит понимать, что может помешать применению этой методики.

    Reply
  56. verter.me

    (55) bsuray, Согласен, простой программистов из-за отсутствия постановки задачи — это проблема. Одно из решений — не иметь под собой вообще программистов. Будет необходимость, формализовали задачу. При наличии готовых заданий на разработку, найти исполнителя вполне реально.

    Reply
  57. McCoy77

    Подскажите, каким редактором пользуетесь при создании Кейсов? И чем рисуете блок-схемы?

    Reply
  58. verter.me

    (58) McCoy77, схемы рисую с помощью MS Visio, сам документ делаю в Pages при необходимости выгружаю из него в Word (но это редко, в основном выгружаю в PDF, он тогда красивый получается)

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *