Оценивать задачу всегда сложно. Постараюсь описать именно свой субъективный опыт в этом вопросе, чтобы помочь коллегам решить подобный вопрос.
Сразу оговорюсь, у меня до сих пор не всегда получается оценивать задачи адекватно (во всяком случае, не всегда моё ощущение адекватности совпадает с ощущениями других участников процесса). Именно по причине того, что вопрос для меня актуальный, хочу поделиться своими размышлениями, и только о технической оценке. Иногда по "политическим" мотивам техническую оценку необходимо уменьшить или увеличить, но данный вопрос не будем рассматривать. Также в статье не рассматривается вопрос торгов по оценке и переоценка в процессе выполнения задачи.
В нашей работе приходиться оценивать задачи с некоторыми неизвестными факторами. Чем их больше, тем больше мозг "бунтует" и сопротивляется решению вопроса. Обычно сопротивление мозга проявляется в беспокойстве, страхах, т.к. с одной стороны возникает страх завысить оценку и показаться некомпетентным или остаться без задачи или даже без клиента, с другой стороны страшно не учесть "подводных камней" и в будущем сидеть часами, а то и днями, делая неоплачиваемую работу.
Соответственно, чтобы оценить задачу хорошо, надо исключить два вышеуказанных страха. Но сначала надо определиться, что же означает оценить задачу "хорошо".
В моем понимании хорошая оценка – это ясная оценка, которую всегда можно аргументировать и которая позволяет комфортно приступить к работе (для каждого конкретного исполнителя это субъективное понятие). То есть, если заказчик или менеджер считают, что Вы оценили задачу слишком дорого, это совершенно не означает того, что задача оценена плохо. При этом, как правило, чем меньше опыта у сотрудника, тем меньшую оценку он будет давать, переоценивая свои возможности, попадаясь в ловушку первого страха – показаться некомпетентным. С точки зрения заказчика эта оценка будет хорошей.
Хорошей оценкой в этой статье будет считаться ясная и комфортная оценка для исполнителя.
Теперь вернёмся к страхам. Страхи переоценить и недооценить задачи появляются не на пустом месте. Заказчики иногда выражают недовольство оценкой в категоричной форме с переходом на личности. Почти всем в нашем деле знакома обратная ситуация, когда несколько дней работаешь бесплатно, подгоняемый недовольным клиентом, что с задачей на восемь часов "копошатся" третьи сутки. Негативный опыт формирует страх ошибиться в дальнейшем, т.к. наш мозг работает по довольно примитивной схеме запоминания паттернов поведения. Чтобы не повторить подобные ошибки, некоторые вообще отказываются давать оценки заранее. Считаю, что это самый простой и неверный выход из ситуации.
Теперь перейдём к путям решения данной проблемы. Борьбу со страхами, которые не позволяют трезво и аргументированно подойти к оценке, надо начинать с чего-то приятного. Например, с верхней границы вилки оценки задачи.
Когда мне говорят, что не могут оценить задачу даже вилкой, я обычно сначала уточняю: "За миллион часов сделаешь?". На что чаще всего получаю утвердительный ответ и сомнение в моей адекватности. После того как с "небом" мы определились, стоит определиться с "землёй". Следующий вопрос: "А за два часа?". На этот вопрос получаю предсказуемое "Нет", т.к. в противном случае ко мне не обратились бы за помощью. Далее играя в "больше, меньше", разрыв сокращается и получается вилка, которую назовём первичной.
Для примера, попытаемся оценить задачу "Надо разработать обработку загрузки поступлений товаров и услуг в 1С:Бухгалтерию предприятия из xml файлов, выгруженных из другой программы". В текущей постановке (а именно так чаще всего приходят задачи от заказчика) совершенно не ясно, сколько это будет стоить, но первичную вилку сможет дать практически любой программист, знакомый с 1С:Бухгалтерией предприятия. Она будет скажем: от 6 до 100 часов. Это уже что-то.
С нижней оценкой всё понятно - она рассчитана методом "если повезет".
А как возникает верхняя граница оценки? Выясняется, что верхняя граница возникает из-за того, что исполнитель, например, толком не понимает, что делать, или из-за того, что заказчик ранее постоянно уточнял свои требования к интерфейсу по уже оцененной и выполненной задаче. Конкретных причин верхней оценки может быть много, но самая главная: "непонимание, что нужно делать".
Если непонимание связано с тем, что вы никогда не работали с ЗУП, а задача "сделать так, чтобы расчетные листки формировались корректно", то первое, о чём стоит подумать – это отказ от данной задачи. Если в силу определенных обстоятельств отказ практически невозможен, будьте готовы, что комфортную оценку вы не получите, и это неплохо, т.к. опыт тоже дорого стоит. Чтобы минимизировать риски, обращайтесь за помощью к тем, кто имел опыт решения подобных задач. Остальные причины верхних границ нужно прописывать в конкретных требованиях или ограничениях, а также снимать риски вопросами.
С ограничениями всё просто. На моей практике заказчик всегда адекватно относился к большому перечню ограничений. Накапливайте свой перечень ограничений от каждой задачи, т.к. зачастую в разных задачах одни и те же риски. В примере с загрузкой из xml, в оценку можно включить разработку обработки, написание инструкции, а в ограничениях прописать, что в оценку не входят: консультации пользователей по работе с обработкой; настройка ролей и интерфейсов; доработка в связи с изменениями конфигурации заказчиком или третьей стороной; доработка из-за изменения формата xml.
Задать вопросы и запросить дополнительные детали сложнее. Здесь опять появляется опасение показаться некомпетентным. Порой совершенно безобидный вопрос расценивается как отсутствие знаний. Постарайтесь перебороть этот страх. Вопросы задавать можно и нужно.
Один из самых высококвалифицированных программистов, с которым мне посчастливилось работать, начинал задавать самые простые вопросы, когда у него появлялась новая задача. Как правило, его собеседник сперва снисходительно отвечал на явно пустяковые вопросы, но чем дальше, тем больше понимал, как много для него самого неясностей. Рассказывали случай, как целый отдел методологов крупной компании взял паузу на неделю, чтобы ответить на вопрос, поставленный этим программистом. Фиксируйте все ответы, даже неадекватные ответы.
Например, если в шаблоне и примере данных нет необходимых для загрузки договоров полей, на вопросы "Есть ли данные по договору в другой учетной системе, аналоге документа поступления? Могут ли специалисты другой учетной системы дополнительно выгрузить номер и дату договора?", вам может быть дан ответ "Мы не программисты и этого не знаем". Для вас это означает, что оценку можно аргументированно повысить, так как дополнительно, с помощью заказчика (это отдельно прописать) предстоит анализ и общение со специалистами другой учетной системы.
Непрофессионально обращаться с одним и тем же вопросом дважды, ответы не должны теряться. Для фиксации ответов на устные вопросы после разговора обязательно отправьте письмо с ответами и просьбой подтвердить их. В дальнейшем эти ответы позволят вам аргументировать оценку.
В примере с разработкой загрузки из xml, очевидно, что первым делом нужно запросить шаблон xml файла, а также примеры выгрузок и конфигурацию заказчика.
После просмотра примеров возникают вопросы, ответы на которые напрямую влияют на оценку, например: «Надо создавать новый элемент справочника "Контрагенты", если по указанным в файле полям поиска (допустим "ИНН, КПП") контрагент не найден или выдавать ошибку? Надо ли создавать новые элементы справочников "Номенклатура", если по полю поиска (допустим "Код в другой системе учета") элементы не найдены? Поступление товаров и услуг в нашем случае формируется только на товары, или материалы и услуги тоже могут присутствовать? Откуда брать недостающую информацию для создания элементов справочников "Контрагенты", "Номенклатура"? Обработка должна запускаться вручную или автоматически по расписанию? Расчеты с контрагентами ведутся только в рублях или в условных единицах и иной валюте также?»
Составить требования еще сложнее, чем задать вопросы. Иногда требования не ясны как заказчику, так и исполнителю. Вносить ясность – это значит тратить время, а будет оно оплачено или не будет, еще вопрос. В таких ситуациях нужно попробовать проговорить с заказчиком оплатить постановку задачи. Порой заказчик считает, что исполнитель не профессионален, если не понимает требования. Это зачастую правда и здесь опять же стоит трезво оценить: браться за задачу или нет. Если при всех подводных камнях, которые по ряду обстоятельств нельзя оценить на берегу (на то они и подводные), вы все равно считаете целесообразным взяться за задачу, то беритесь и пусть ваша оценка будет неверная. Риски, на которые вы идете в таком случае – осознанные.
Если требования вам понятны и очевидны, не поленитесь их прописать. Другим участникам процесса они могут быть не понятны. Недопонимание – ключевая проблема в нашей работе. Как правильно писать требования – это тема отдельной статьи, но писать их нужно обязательно.
После того как требования определены, разложите задачу на подзадачи. Чем больше, тем лучше. Стоит также указать подзадачи, необходимые для сдачи работ, например: составление контрольного примера тестирования, тестирование согласно контрольному примеру. Также стоит указать перечень подзадач, которые должен выполнить заказчик для обеспечения возможности вашей работы, например: утверждение формата выгрузки, нормализация НСИ. Будьте готовы, что после выделения подзадач, оценка может существенно поменяться, это нормально. Могут также появиться новые вопросы и требования.
Подзадачи для нашего примера:
- Согласование с разработчиками другой учетной системы (через заказчика) полей поиска элементов справочника "Договоры контрагентов" и изменение формата выгрузки: 2 - 8 часов
- Утверждение формата выгрузки из другой учетной системы - 0 часов (работа заказчика)
- Разработка функционала для сопоставления текущих договоров с полями, выгруженными из другой учетной системы - 0 - 8 часов.
- Сопоставление договоров 1С и кодов другой учетной системы - 0 часов (работа заказчика)
- Подготовка шаблона Excel для ручного заполнения соответствий кодов другой учетной системы и номенклатуры (иерархически): 2 часа
- Сопоставление номенклатуры 1С и кодов другой учетной системы - 0 часов (работа заказчика)
- Загрузка значений дополнительного свойства "Код другой учетной системы" справочника "Номенклатура" из Excel: 2 - 4 часа
- Разработка алгоритма создания элементов справочника "Номенклатура" по коду другой учетной системы и наименованию: 2 часа
- Разработка обработки загрузки поступлений товаров и услуг из xml: 8 - 12 часов
- Разработка регламентного задания (для автоматического запуска по расписанию) - 2 часа
- Подготовка инструкции (по настройке расписания и запуску обработки) - 4 часа
- Составление контрольных примеров (один документ на каждый пример), подготовка тестовой среды: поступление без НДС, поступление с НДС 18%, поступление с ошибкой по контрагенту (не найден по ИНН/КПП), поступление с созданием новой номенклатуры: 2 - 3 часа
Тестирование обработки согласно контрольным примерам, составление протокола тестирования: 4 часа
После того как будут получены ответы на вопросы, прописаны конкретные требования и ограничения, а также задача будет разложена по подзадачам - вилка оценки скорее всего будет приемлемой. В нашем примере: 28 - 49 часов.
Не надо бояться, если вилка по прежнему с большим разбросом, главное, что вы сами понимаете причину разброса и можете её аргументировать.
Если заказчик настаивает на четкой оценке, выставляйте верхнюю границу. Страхи исчезнут сами, т.к. на любой вопрос по оценке вы будете готовы предоставить аргументы.
Итак, выдержка по оценки задач:
1. Прикиньте максимум и минимум затрат. Неважно, что оценки могут отличаться в разы
2. Задавайте вопросы, фиксируйте ответы
3. Прописывайте ограничения
4. Прописывайте конкретные требования
5. Разделите задачу на подзадачи
6. Скорректируйте первоначальную вилку, не стремитесь, чтобы она обязательно была узкой. Стремитесь к тому, чтобы любой пункт оценки вы смогли аргументировать
7. Не бойтесь ошибаться в оценке, если задачу целесообразно решить по отличным от "меркантильных" мотивам
Тем, кому интересно изучить данный вопрос подробнее, советую почитать книгу Стива Макконнелла "Сколько стоит программный проект".
