Содержание
1. Ошибки программистов и удаленных разработчиков
2. Ошибки аналитиков – консультантов
3. Ошибки при оценке последовательности проведения работ
Для кого эта статья? Если вы руководитель проектов (РП) с опытом «от трех проектов», то можете не читать: скорее всего, ничего нового вы не узнаете. А если вы хотите стать РП в проектах 1С или вы профессионал (разработчик, аналитик, консультант), к которому часто обращаются за оценкой, то вам будет полезно узнать о типичных ошибках при оценке.
Если вам необходимо реализовать задачу, которую не имеет смысла делать по классической проектной технологии, но заказчик требует фиксированной оценки, и задача на 2-5 человеко-месяцев, - то вам будет полезно понять методы оценки работ.
Если читатель часто пользуется услугами удаленных разработчиков/аналитиков, то вам, возможно, станет понятно, почему «человек все сделал, мы ему заплатили, сколько сказал, а он от нас ушел и больше работать не хочет».
Типичные ошибки распределю по классам.
1. Ошибки программистов и удаленных разработчиков
1.1. Недооценка времени на тестирование и исправление.
Подумайте, вы правда умеете программировать сразу без ошибок? Если нет, смело закладывайте время на тестирование. Сколько? Зависит от задачи – вы профессионал, вам виднее.
1.2. Недооценка времени на уточнение формулировок задачи проекта.
Вам сразу понятно ТЗ? Точно сразу? Вы точно понимаете, что постановщик задачи вам сказал? Скорее всего нет. И это правильно – полностью формализовать ТЗ до уровня всех алгоритмов никто не будет (а особенно заказчик). А это значит, что вам придется уточнять постановку задачи. И это нормально. Заложите на это время, если задача большая.
1.3. Недооценка времени на подготовку к работе.
Где будет происходить разработка? У вас на компьютере? На сервере заказчика? На сервере компании? А база уже развернута? А есть доступ? А получен ли cf, если «конфигурация заказчика немного изменена»? Эти вопросы надо задать и понять, потребуется ли время на подготовку. Если потребуется, и подготавливать будете Вы, включайте время в оценку.
1.4. Недооценка сдачи-приемки.
Подумайте, кому и каким образом вы будете сдавать работу? Что для этого потребуется? Сколько это займет времени? Вы сдаете работу не одному человеку, а нескольким (такое бывает)?
1.5. Недооценка окружения.
Заказчик использует хранилище конфигурации, разработка ведется в расширении, «вот вам простой и понятный регламент работы и документирования кода всего на 25 страницах»? Если вы с этим работали, то понимаете: на сколько умножить, если работа с хранилищем; на сколько, если с расширением; сколько процентов на страницу регламента закладывать. Если не работали – смело умножайте на 1.5 за каждый вид неопределенности. Скорее всего, все равно не угадаете, но это будет не так обидно.
1.6. Не указали границы.
Вы оценивали, как будто будете делать у себя, а заказчик сказал, что вся разработка только у него на сервере, а там см. предыдущий пункт. И, конечно же, при постановке задачи этого не было сказано.
Тут 100% действующего рецепта нет – при постановке задачи не сказать могут что угодно. Если условия неизвестны, пишите свои предположения и их считайте «границей». Если вы имели ввиду, что вы только кодируете, только у себя, а в качестве сдачи-приемки отправляете cf по почте – напишите. Заказчик либо согласится, либо задумается и скажет: «Нет, я хочу, чтобы вы мне тестовый стенд развернули и показали, как это работает». Тогда вы уже вступаете в конструктивный диалог: «А тогда это будет стоить еще…». В любом случае, вы не будете работать бесплатно: если выяснится, что заказчик не готов за что-то платить, вы сами примете решение, готовы вы что-то сделать за бесплатно, или пусть поищет кого другого.
Указанные пункты не являются панацеей. Ошибиться с оценкой можно даже учтя их все, например, автор регулярно так делает (в смысле ошибается с оценкой).
2. Ошибки аналитиков – консультантов
Если вы программист, но задачи вам ставит заказчик, то вы выполняете и эту работу тоже. Можно смело читать.
2.1. Правильно расписана последовательность работ.
Вы же понимаете, как будете решать поставленную задачу? В какой последовательности? Что будет результатом? Если понимаете, то напишите эту последовательность. Лучше всего в MSProject. Так вам станет понятно, когда вы на самом деле сделаете задачу.
2.2. Не заложен резерв под исправление ошибок.
Может ли ваш результат содержать ошибки? Скажем, в инструкции? Если может, то закладывайте время на исправление ошибок.
2.3. Не заложен резерв под сдачу-приемку выполненных работ.
Как вы будете сдавать работу? Кому? Сколько это на самом деле займет времени? Надо ли будет куда-то ехать? Надо ли там кого-то ждать? Сможете ли вы сделать что-то еще, если поедете сдавать задачу к заказчику на Рябиновую улицу к 15? Если нет, то почему бы не включить часы вынужденного простоя в часы работы на заказчика, из-за которого этот простой вызван?
2.4. Не учитываете транзакционные издержки.
Что это такое? Очень просто. Например, у вас мини-проект и вы договорились о серии интервью для уточнения задачи. И вот первое интервью у вас в 10:00, а второе в 15:00. Чем вы будете заниматься между ними?
Далее. Вы отправили заказчику вопрос. Он точно вам сразу же ответит? А если нет, что вы будете делать, пока ждете ответа? А кто оплатит время вынужденного простоя?
Вы планируете обучение для сотрудников заказчика и предполагаете, что потребуется 40 часов, т.е. рабочая неделя. А сможет ли заказчик выделить своих очень занятых сотрудников на неделю? Нет конечно. А как это будет?
Все такого рода задержки как раз и называются транзакционными издержками. Избежать их полностью не удастся. Я считаю честным подходом рассказать о них заказчику, чтобы он тоже подумал, как бы так организовать работу, чтобы их избежать таких издержек, и не платить вам за простой. Но в каждом конкретном случае решать тому, кто дает оценку.
2.5. Не фиксируете результат, либо фиксируете нечетко.
Это сочетается с пунктов 2.3, 2.4. Подумайте, что будет результатом вашей работы. Если сложно понять, обратитесь к более опытным товарищам, которые объяснят, например, что результат интервью – это протокол, что инструкция по работе – тоже результат. И возвращаясь к п.2.3: сразу подумайте, как вы будете это сдавать, и что является критерием корректно полученного результата. Это избавит вас от прекрасных формулировок вида «корректная работающая система, формирующая правильные проводки» (сам такие делал). Если описание результата допускает двоякую трактовку – будьте уверены, вы с Заказчиком поймете по-разному. Если не допускает, то тоже поймете по-разному, но вам по крайней мере будет что сказать.
3. Ошибки при оценке последовательности проведения работ
Тут пойдет речь об оценке мини-проектов, где будет работать не только аналитик, но и разработчик (или два). В качестве тимлида в таких конструкциях обычно выступает аналитик, который и общается с заказчиком, ставит ТЗ, принимает работы у разработчиков и сдает результат Заказчику.
3.1. Неправильно указана последовательность проведения работ.
Подумайте, как команда будет делать проект. Постарайтесь хотя бы не планировать так, чтобы кто-то делал одновременно две задачи. В реальности все равно так случится и тогда количество одновременных задач умножится на два. Если у вас запланированы две задачи одновременно, то будьте уверены – в какой-то момент их станет 4.
Помните, что разработчики ошибаются с оценкой (см раздел 1).
Помните, что нельзя писать инструкцию по неразработанному функционалу (например).
3.2. Не учтены транзакционные издержки.
Как будет происходить передача задачи от вас программисту? А от программиста к вам? Что он будет делать, пока вы проверяете результат?
3.3. Перегрузка ресурсов.
У вас проект на 9 человеко-месяцев, а надо сделать за один. Казалось бы, берем 9 программистов, и они все сделают за месяц. Но нет! Если один аналитик и девять программистов, то задача будет делаться скорее всего около года. Да-да, та самая, на 9 человеко-месяцев.
Не ваш случай? Так если у вас шесть программистов на 50% загрузки, то это хуже, чем 3 на 100%.
Почему? Потому что как бы не была декомпозирована задача, как бы вы не написали ТЗ, вам будут задавать вопросы при разработке (те самые, из п.1.2) Одному человеку вы объясните один раз. Шести – шесть. И вопросов будет в 6 раз больше.
3.4. Ошибки окружения.
Если у вас работает несколько разработчиков, надо понимать, как вы будете объединять плоды их трудов. Кто и как это будет делать. Каким функционалом. Если будете объединять разные доработки в одной конфигурации, то не забудьте, что делая одно можно сломать другое. И лучше будет, если вы сами это обнаружите, чем «прилетит» от заказчика. А значит, надо заложить дополнительное время на все указанное выше.
Список кончено не исчерпывающий, но основное я указал. Теперь абзац для заказчиков.
Итак, уважаемые заказчики, если вы – получатель оценки, то надо все эти вопросы (из пунктов 1-2) задавать вашему исполнителю. Иначе может получиться, что ваш исполнитель получит существенно меньше, чем потратит времени. А вам-то что? Очень просто: он пару раз с вами поработает, а потом решит, что ему так не надо. И либо скажет, что больше не хочет так работать, либо просто исчезнет (хорошо если без предоплаты). Потому если вы нацелены на долгое сотрудничество – задавайте эти вопросы. Цените специалистов, проводящих работы в программе 1С, их и так мало!
Специалист компании «Кодерлайн»
Иван Аюпов
