Как решать IT-кейс?

Кейс-чемпионат ― отличная возможность научиться решать реальные задачи компаний, особенно если вы хотите работать в сфере IT. Теперь быть просто хорошим программистом недостаточно, важно уметь работать в команде и знать подходы к организации работы в IT-проекте. А где еще потренироваться во всем этом, как не на кейс-чемпионате, например, Changellenge >> Cup Technical? Наши слова подтверждает Андрей Попов, руководитель дирекции информационных технологий Райффайзенбанка. Он рассказал о частых ошибках, которые делают молодые IT-команды, распределяя роли и презентуя свои решения, и дал советы, как лучше организовать работу над кейсом.

Как вы думаете, важен ли опыт участия в таких кейс-чемпионатах, если человек хочет попасть на стажировку или на постоянную позицию, например в IT-департамент Райффайзенбанка?

Андрей Попов. Будет ли это решающим фактором, зависит от успеха и полученного на чемпионате опыта. Но это однозначно плюс кандидату! Сейчас мы стремимся привлекать динамичных, заинтересованных и энергичных сотрудников, поэтому опыт участия в кейс-чемпионате точно привлек бы мое внимание.

Какие ошибки в командной работе мешают участникам взаимодействовать друг с другом?

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

Есть ли какие-то особенности распределения ролей в IT-проекте и IT-команде?

А. П. Здесь все напрямую связано с навыками и знаниями участников и зависит от потребностей команды в каждый конкретный момент. Один человек может исполнять разные роли, одна роль может быть исполнена разными людьми. Сильный аналитик может помочь с тестированием, разработчик, тонко чувствующий эстетику, станет партнером для дизайнера. Важно, чтобы команда понимала свою цель, что и зачем она делает, чувствовала свое единство, была гибкой. Тогда будет легче распределиться по ролям. Если говорить о самих ролях, то вот логичный, на мой взгляд, состав команды на чемпионате: лидер, аналитик, архитектор, разработчик, проектировщик и дизайнер.

Если участники команды знакомы недавно и к тому же у всех разный бэкграунд (например, не все из сферы IT), что сделать, чтобы они друг друга понимали и взаимодействие привело к результату?

А. П. Первая задача для любой команды ― выбрать лидера, того, кто сможет наладить общение внутри, поможет другим участникам понять, кто что умеет и знает. После знакомства участников команды друг с другом, я бы применил метод «мозгового штурма»: накидал бы разных, самых, возможно, сумасшедших и невероятных идей. В этой фазе важно воздержаться от критичных и категоричных заявлений вроде: «Так делать нельзя», «Это работать не будет». Команда и так ограничена во времени, ресурсах и знаниях, не надо насильственно создавать дополнительные преграды. Набрав достаточное количество идей, на следующем этапе можно уже отсеивать наименее реалистичные.

Если провести параллель между кейсами и реальными проектами в банке, как у вас строится взаимодействие между участниками команды, например, разработчиками и аналитиками?

А. П. Мы стремимся к тому, чтобы внутри команды были специалисты, способные выполнять разные роли. Если команда жестко делится на узких специалистов (разработчика, проектировщика, инженера поддержки, тестировщика и дизайнера), это делает ее очень костной и неповоротливой. А вот способность команды динамично менять акценты и смещать фокусы ее участников — значительный фактор успеха. Гибкий и пластичный в своих знаниях и умениях человек может сыграть множество ролей, и чем их больше, тем он ценнее для команды.

Какие подходы к решению задач и организации работы над проектами есть в IT? Agile, Scrum — есть ли что-то еще? И какие подходы могут использовать команды, участвующие в кейс-чемпионате?

А. П. Agile — это целая философия, культура. Она касается не только IT-сферы — маркетинговое агентство тоже может быть agile. Методик, которые помогают организовать работу в соответствии с принципами Agile, много. Scrum,экстремальное программирование (XP), Test driven development, Kanban. Какую методику выберет команда неважно, важно — понимать, что и зачем вы делаете. Если говорить о небольшой команде, у которой жестко ограниченно время на решение кейса, то лучше всего, наверное, подойдет методика XP, когда над каждым этапом работают несколько членов команды.

Что еще вы посоветовали бы команде, работающей над кейсом?

А. П. Не старайтесь сделать всё сразу, описать абсолютно всю спецификацию или архитектуру проекта. Попробуйте создать что-то небольшое, сразу проверьте и сделайте выводы: работает или нет. Если не работает, ищите, что поменять, если работает, двигайтесь дальше или совершенствуйте то, что есть.

Давайте поговорим о финальном этапе — презентации решения. Если воспринимать ее как презентацию стартапа перед инвесторами, на что ребятам стоит обратить внимание?

А. П. Прежде всего, команда должна объяснить, какую проблему решает их идея. Нужно четко сформулировать мысль: то, что мы сделали, отвечает на такой-то вопрос и позволяет удовлетворить такую-то потребность. Решение не должно быть слишком вычурным или чересчур экстравагантным, но изюминка, попытка посмотреть на проблему с необычного ракурса должна присутствовать. В этом виден дух команды, это уже не механика, а творчество, хорошая и даже, возможно, дерзкая идея. Как говорится, целься в звёзды, чтобы долететь до Луны.

Сейчас Райффайзенбанк работает со стартапами, вы смотрите молодые IT-команды. На что ориентируетесь при отборе?

А. П. Смотрю, насколько интересно ребята сформулировали проблему, насколько неординарно, элегантно, эффектно и эффективно они попытались ее решить. Приятно видеть, когда команда по-настоящему погрузилась в задачу, а не прошлась по верхам из серии «А не построить ли нам космический корабль и не покрасить ли его в розовый цвет?». Интересно, когда команда увидела какую-то болевую точку на примере себя, своих друзей, близких или каких-то наблюдений и попыталась эту боль снять.

Какие ошибки совершают молодые команды?

А. П. Бывает так, что команды начинают хвастаться. Ударяются в какой-то, простите, фетишизм элегантности найденного решения. Начинается самолюбование, увлеченность своей идеей, в то время как проблема, которую они решали, оказывается неочевидной. Если ты считаешь что-то проблемой, но не можешь объяснить, почему и для кого это является проблемой, и при этом демонстрируешь какое-то феноменальное решение, есть сомнение, что у такого решения будет рынок, что за продукт кто-то заплатит и будет им пользоваться. Если проблемы действительно нет, то насколько бы элегантным решение ни было, оно никому не нужно. Важно не увлекаться этим, а определить настоящую проблему и объяснить, почему ваше решение поможет.

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

А. П. В реальной жизни никогда не бывает слишком много времени или ресурсов. Одно из возможных лекарств, которое поможет уменьшить последствия этой неопределенности, зажатости, ограниченности, — итеративность. В конце каждой итерации у вас должен получиться прототип, который уже можно опробовать, пощупать и оценить. Если вам не хватит времени реализовать задуманное на 100 %, вы всё равно сможете показать работающую версию продукта, а не только презентацию о том, как будет здорово, если кто-нибудь когда-нибудь воплотит ваш проект в жизнь.

А что, если в команде творческий кризис? Что делать, если закончились идеи?

А. П. Немного отвлечься: можно поиграть минут пятнадцать в приставку или пойти подышать воздухом. Попытаться отступить на пять-десять шагов назад или провести ещё одну сессию мозгового штурма. Не нужно бояться экспериментировать, даже если вы чего-то не знаете. Не хватает данных? Предположите, какими они могли бы быть. Не хватает знаний в конкретной области? Пробегитесь хотя бы по верхам, чтобы получить представление о теме, построить и проверить какую-то гипотезу. Если гипотеза не сработала, тоже хорошо! Вероятность, что вы найдете правильное решение на следующем шаге, увеличивается.

Чтобы генерировать идеи, важно разбираться в тенденциях. На какие тренды посоветуете обратить внимание? Что почитать?

А. П. Можно почитать «Хабр» — там бывает много интересного. Можно посмотреть сайт Stack Overflow. В поисках эстетического вдохновения и идей по программированию полезно изучить документацию, например, HIG, и девелоперские секции сайтов гигантов вроде Google, Apple,Microsoft. Мир сегодня очень динамичный, мобильный. Смотрите на повседневную жизнь, мобильные устройства, которые носите с собой. Еще один тренд — интеграция с социальными данными, большими данными, инструментами машинного обучения. Это очень интересно, вопрос только в том, насколько реально по времени. Обратите внимание на инструменты вроде TensorFlow у Google, которые позволяют выстраивать собственные нейронные сети для машинного обучения, превентивного анализа. Кейс-чемпионат — отличная возможность научиться решать реальные задачи компаний, особенно если вы хотите работать в сфере IT. Теперь быть просто хорошим программистом недостаточно, важно уметь работать в команде и знать подходы к организации работы в IT-проекте. А где еще потренироваться во всем этом, как не на кейс-чемпионате, например, Changellenge >> Cup Technical? Наши слова подтверждает Андрей Попов, руководитель дирекции информационных технологий Райффайзенбанка. Он рассказал о частых ошибках, которые делают молодые IT-команды, распределяя роли и презентуя свои решения, и дал советы, как лучше организовать работу над кейсом.

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