Александр Мирзахмедов, руководитель проекта
Так получилось, что в прошлом году я сменил не просто работу, но и область деятельности в IT. Из продуктовой компании, в которой делают большие и сложные продукты с использованием Java, C, C++, C#, JavaScript и даже в FPGA для ПЛИС, я попал в мир 1С, где огромная роль и часть работы над ИС остаётся за аналитиками. Очень быстро я обратил внимание на то, как мало распространено в этом мире то, что я принимал за основу ранее. Здесь свои законы, правила, подходы, методики, но есть и те, кто пытается принести новшества в свою работу.
Ранее, я уже писал о том, что «гибкие методологии» работы тут не являются чем-то обыденным и обиходным, и что уж больно сильно их мифологизируют, нарываясь на необязательные рифы.
Дело в том, что коллеги в поисках информации, обращаются к Google, и принимают за канон в том числе поверхностные материалы о чьём-то опыте, вместо того, чтобы уделить время изучению «мат. части» в оригинале. Например, Scrum надо внедрять не по видео в YouTube, а по Scrum гайду. Ну, это сугубо моё личное мнение 😊
В этой статье поделюсь, что ещё можно «стащить» у коллег в IT, кто уже давно практикует решение серьёзнейших задач за короткие сроки.
— А что, так можно было?! — спросите вы.
— Конечно же нет, — отвечу я.
Но на деле, ответ «нет» будет неточным. Можно, но отчасти. Отчасти, потому что только часть может быть сделана в короткий, в данном контексте – недостаточный, срок. Например, такой частью может быть то самое MVP, правильно сформировав которое можно вытащить даже слабенький стартап. Но сейчас мы не о стартапах.
Берём только лучшее
«Для того, чтобы продать что-то, надо сперва купить что-то», — говорил один полосатый персонаж. Ну, а для того, чтобы сделать часть, надо эту часть отделить. И не как кусочек от тортика отрезать, а собрать из множества мелких деталей ту самую часть, которая:
1. Предельно понятна в производстве и в дальнейшем использовании.
- Требования к ней ясны.
- Есть источники данных. Данные в них пригодны для использования.
- Есть силы и средства для её реализации. У обеих сторон.
2. Определённо принесёт пользу и желательно по закону Парето.
3. Устранит сомнения и страхи Заказчика. Продвинет Исполнителя в понимании специфики Заказчика.
У вас бывало такое, что вроде проект понятный, все слова знакомы, но как начать — не знаете? Тогда держите один из ключевых инструментов, позволяющих эффективно решать задачи — декомпозицию.
Сплошная польза
Декомпозиция задач – это процесс разбиения сложной задачи на более простые и понятные подзадачи. Подзадачи могут быть ещё более детально разбиты на подподзадачи, пока каждая из них не станет настолько простой, что её можно легко решить. Почти как фракталы, но не совсем.
Чего же мы добиваемся этим разбиением?
Упрощаем сложные задачи
Сложные задачи могут быть очень трудными для решения. Однако, если разбить сложную задачу на более простые подзадачи, то она становится более управляемой и легче решаемой. Таким образом, декомпозиция задач помогает упростить сложные задачи и решить их более эффективно.
Знаете, даже большущие профессионалы иногда тупят. Когда это случается, они делают ошибки. Порой эти ошибки заводят их либо в тупик, либо запускают в цикл. Всё это чревато переработками, конфликтами и выгоранием. Вот тогда и начинается настоящий кошмар. А всего-то – не разбили большую задачу и пытались «есть слона целиком». И ведь даже «сеньоры» так выгорают!
Улучшаем коммуникацию
Декомпозиция задач помогает улучшить коммуникацию между членами команды. Каждый может лучше понимать свою задачу и свою роль в общей задаче. Это позволяет более эффективно координировать работу всей команды.
Другой пример пользы могу привести из реальной ситуации. Аналитик никак не мог понять, как ему выполнить работу, потому что в названии процесса стояло всего лишь одно «лишнее» для него слово. И пока задачу не разобрали на составляющие, не нашли для него аналоги того, что он делал ранее, не применили эти лекала к «непонятной» задаче, так и стояли бы на месте.
Увеличиваем скорость выполнения задач
Декомпозиция позволяет ускорить выполнение сложных задач. Каждая подзадача может быть решена отдельно и параллельно, что сокращает время выполнения общей задачи. В конце концов, у вас всегда есть возможность привлечь специалистов «подешевле», чтобы затащить задачи, которые мастерски «нарезал» тот, кто существенно дороже.
Уменьшаем риски
Разбиение задач на более мелкие подзадачи помогает уменьшить риски, связанные с выполнением задачи. Если в процессе решения одной из подзадач возникают трудности, то это не повлияет на решение других подзадач и не задержит выполнение общей задачи.
Как-то раз столкнулся с тем, что аналитик мне на двухнедельный «спринт» принес один цельный лист требований (ЛТ). По его составу легко можно было выделить сразу шесть ЛТ, и они, в свою очередь, разбились бы на еще несколько каждый. Пока я не объяснил «А вот заказчик у тебя не примет работу из-за этой строчки, значит и оплату не получим вовремя из-за неё одной за весь спринт!», чувствовал себя человеком, который лишнюю работу придумал хорошему человеку. Лучше встрять по одному ЛТ из 10, чем по одному единственному, но большому.
Принципы декомпозиции задач
Простые рецепты бывают только в «лохотронах», а потому, засучите рукава вашего сознания, и впитывайте принципы правильного подхода к предмету.
Декомпозиция задач – это не просто разбиение сложной задачи на более простые подзадачи. Это процесс, который требует определенных принципов и правил. Вот некоторые из них:
- Каждая подзадача должна быть независимой от остальных задач в семье отщепенцев от родительской задачи. Иначе, ни о какой параллельности выполнения и речи быть не может.
- Каждая подзадача должна быть понятной и конкретной. Конкретнее, чем мужики в малиновых пиджаках в 90-е. Надо сделать так, чтобы было легко понять и выполнить. Если подзадача слишком абстрактная или неопределённая, то ничего хорошего вас не ждёт в конце.
- Размер подзадачи должен быть оптимальным, чтобы её можно было выполнить за определённое время и с определёнными ресурсами. Помните, что у вас в целом есть сроки на проекте? Кстати, полностью и правильно декомпозированный проект легко оценить сразу. От таки дела, малята!
- Подзадачи должны быть связаны между собой и приводить к общей цели. Управляйте рисками и контролируйте выполнение, чтобы достичь именно того, что требовалось, а не того, что подумал каждый из участников процесса и делал без оглядки на остальных.
Вместо заключения
В РП можно прийти с разных сторон. Я пришёл из аналитиков (нет, не 1С). И конечно же на накрытую поляну.
Мне предстояло за короткий срок подготовить релиз продукта, который был к нему совсем не готов. Команда была на нервах - бросить и уйти уже было вариантом для отдельных ребят. Когда я понял, что у меня команда сидит со «слоном во рту» у каждого, я каждый день шарил экран, заходил в Jira, открывал задачу на этого «слона» и начинал последовательно задавать вопрос «как именно?», расписывая шаги.
Скептицизм и ирония коллег по отношению к моим действиям улетучились вместе с первыми успешно решенными задачами. Ребята активно вовлекались, помогали в формулировках друг-другу. Они берегли меня абстракцией от особенностей языка, паттернов проектирования и прочих тонкостей, которые были абсолютно не нужны. Мы успешно выпустились тогда в срок. Сделали ту часть, которую реально можно было понять в хитросплетениях плохо поставленных задач и отсутствия информации с этапа ППО. Остальное показали руководителю и отправили требования на доработку.
А что Заказчик спросите вы? Ну во-первых, Заказчику нужен результат. И вы его ему даёте. Тот кусок, который невозможно переварить или у вас не хватает требований и информации, всегда можно предъявить Заказчику и спросить «ну вот мил, человек, сам то понимаешь, что ты хочешь?». Всяко лучше сдать ему часть работы, иногда даже значительную, ну а остальное … Зависит от вашего умения ясно излагать мысли и использовать факты.
И да, садитесь с Заказчиком в режиме шаринга экрана и… А как иначе? Мы ведь тут за это деньги получаем! 😊