Исследовательские задачи
Постоянная беда айти-индустрии — сползание сроков, причем по «объективной» причине: недооценили задачу.
Казалось, что работы на три дня — а «оказалось, что показалось».
Страховочными методами, т.е закладыванием времени на непредвиденные проблемы, этот вопрос ультимативно не решается, только сглаживается ситуационно. Заложи на риски плюс день — всегда можно обосраться на неделю, заложи неделю — уйдет месяц, домножь сроки на два — можно накосячить и больше, вместе с тем получив сразу вопрос «а с хрена ли сроки у вас такие конские».
В хорошем вопросе всегда есть намек на ответ: риски надо снижать.
Отдельный привет сообществу open source, которое имеет обычно ворох решений для очевидных задач, когда каждое решение может принести ворох дополнительных непредвиденных проблем. Не поддерживается, не совместимо, просто не дописано и никем не проверялось, автор(ы) давно положили болт на PR и доработку решения, энтузиазм иссяк итп.
Мой персонально встреченный теперь любимый случай, когда в 2023 году пакет одного из мейнстримных решений для цифровых радиотрактов частично базируется на небольшом тулките 2019 года — который уже к дате устарел лет на 5.
При попытке понять, что же думал автор выясняется, что автор благополучно скончался в 2013 м, а в 2019 сборку пакета обновлял его испанский кореш «в память об ушедшем друге». Разумеется, в 2019 ему было уже глубоко пофиг на детали реализации.
Вот код, ему 10 лет, хочешь — перепиши сам если тебе надо. Опенсорц же.
Единственный способ узнать о работоспособности — это целиком попробовать. Или найти того, кто пробовал. Время и сроки не узнаешь нигде, тебе надо, ты и разбирайся.
С одной стороны, у нас есть задачи с непонятным уровнем неизвестности и рисков.
С другой стороны, предсказуемо оценить мы можем только те задачи, где непонятности, неизвестности и риски сведены к минимуму.
Вот их и надо снижать в первую очередь.
Но как оценить и работать с тем, чего ты не знаешь?
Это беда индустрии. Заказчику хочется верить, что волшебный конструктор соберется предсказуемо и в срок; IT-специалисты с красными глазами ночами пытаются собрать из разношерстных компонентов в срок хоть что-то, что рамочно будет похоже на работающее — и при этом не просрать сроки.
Привкус магии и алхимии, вперемешку с кофе и матом присутствует на местах, куда периодически заглядывают ПМы и заказчик, с вопросом «ну как там».
Для каждой задачи (рекомендую) следует на берегу попробовать оценить: насколько она предсказуемая, проверенная и понятная.
— хороший случай: да, мы это делали уже, вон лежит проверенный код, он вон там работает, счас вкрутим
— менее хороший: мы этого не делали, но вот здесь работает, есть вот такие 1-2 варианта как сделать
— уже рисковый: как-то так оно делается, интернет вроде пишет что работать должно
— совсем неуютно: готового решения нет, есть описанные подходы
В последнем случае вы рискуете прийти к тому, что решение себе вы будете писать с нуля. Максимально времязатратный и непредсказуемый путь, к тому же обычно адски дорогой.
Даже в случае успеха вы потратите время на разработку решения, которое будет напоминать ситуационный костыль, который подходит только к вашему бизнесу (если повезет), никому кроме вас не нужный.
Поддержка целиком ляжет на вас, со всеми затратами — при том, что такой подарок вам вовсе был не нужен на старте, времени и бюджетов, как и рабочих рук, на него не было.
Хорошо если в проекте есть люди, которые умеют решать нестандартные задачи, и фанаты своего дела, которые могут (теоретически) написать еще-пока несуществующее решение чисто по приколу, из научно-прикладного интереса. Есть у вас такие люди со свободным временем? Не факт.
1. Снижать долю исследовательских задач до минимума
Если для задачи сходу не понятно, «как это должно быть сделано» — такая задача под подозрением, следует ее проработать. Либо выносить их в отдельный пул задач, со своими сроками, оценками рисков, ожиданиями, артефактами итп.
2. Выделять исследовательские задачи явно в отдельную категорию
Решать их в первую очередь. Да, это время на исследования — на выходе таких задач нужно получить прототип или proof-of-concept. Да, это время, но это время снижает вам риски и повышает всю остальную предсказуемость. Если предстоит обосраться, то лучше обработать эту ситуацию в начале пути, чем прийти к ней явочным порядком в конце.
Заниматься ресерчем — не стыдно. Не забудьте оформить результат в читаемом виде, чтобы ресерч не остался жить в голове у исследователя.
Самый неочевидный и самый больной пункт. Если вы что-то сделали, должна быть возможность это повторить, с минимальными рисками для себя и для команды. Не «Вася писал, наверное он помнит», а с конкретной инструкцией, артефактами/кодом, руководством по интеграции и/ли с описанными граблями.
Если нет хотя бы зачатков понимания «что хотел сказать автор» и «как это работает», и это нигде не зафиксировано — я гарантирую, что через полгода вы будете «исследовать» задачу заново. Это не так плохо, даже полезно — просто дорого и опять непредсказуемо. И это не «так случилось», это лично вы поленились себе работу упростить. Так не надо.
Очевидно здесь же растёт bus factor, когда всё знал/помнил единственный человек, который уволился полгода назад.
Если вы большие и бородатые, и сто лет на рынке, логично предположить что работа с исследованиями у вас обложена процессами, верно? : D