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

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

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

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

Если говорить о самих ролях, то вот логичный, на мой взгляд, состав команды: лидер, аналитик, проектировщик и дизайнер.

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

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

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

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

Какие подходы к решению задач и организации работы над проектами есть в IT?

Agile — это целая философия, культура. Она касается не только IT-сферы — маркетинговое агентство тоже может быть agile.

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

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

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

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

На что ориентируется жюри при отборе?

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

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

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

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

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

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

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

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

Можно почитать «Хабр» — там бывает много интересного. Можно посмотреть сайт Stack Overflow. В поисках эстетического вдохновения и идей по программированию полезно изучить документацию, например, HIG, и девелоперские секции сайтов гигантов вроде Google, Apple, Microsoft. Мир сегодня очень динамичный, мобильный. Повседневная жизнь заполнена мобильными устройствами, которые носятся с собой. Еще один тренд — интеграция с социальными данными, большими данными, инструментами машинного обучения. Это очень интересно, вопрос только в том, насколько реально по времени. Обратите внимание на инструменты вроде TensorFlow у Google, которые позволяют выстраивать собственные нейронные сети для машинного обучения, превентивного анализа.

 

Iii. Этап. Публичное выступление

Основные требования к power point презентации

СОДЕРЖАНИЕ

1. Мысль должна быть структурирована и четко организована.

2. Презентация должна содержать оглавление и заключение в конце каждого раздела

3. Презентация должна быть наглядной, содержать демонстрации, примеры и цитаты

ФОРМА

1. На презентацию надо смотреть с расстояния зрителя и его глазами

2. Используйте максимум визуальной информации, от графиков до картинок

3. Все однотипные элементы должны быть на одних и тех же местах, одинакового цвета, размера и вида

ВЫСТУПЛЕНИЕ

1. Выступление очень выигрывает от импровизаций и вдохновения

2. Будьте открыты и уверенны в себе

3. Не бойтесь неожиданностей — относитесь к ним спокойно

 

⇐ Предыдущая12

Поделиться: