Привет, Хабр! Меня зовут Игорь Слепко, и днем я обычный middle AQA в МТС Диджитал, но вечером… Вечером меня посещают гениальные идеи. Одна из них была настолько простой и красивой, что я спросил себя: почему никто не разглядел эту жемчужину раньше? Ответ я узнал только после нескольких безуспешных попыток ее реализовать.

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

Ожидание: вдохновленные студенты решают сложные задачи и набираются опыта

Без практики выпускников встречает коронная фраза работодателей «забудьте все, чему вас учили в вузе». Если их, конечно, еще возьмут на первое место работы. Добросовестные преподаватели стараются: придумывают задачи сами, ищут по «сарафанному радио». Но в первом варианте студенты работают в стол, поэтому для них гораздо полезнее реальные и актуальные кейсы.

У малых компаний и некоммерческих организаций без бюджета на ИТ таких небольших проектов много. Можно оформлять их пожелания в задачу, после чего студенты, разделившись на команды, будут ее решать. Так они получат реальный опыт работы, научатся взаимодействию с другими специалистами. Каждый такой проект — комплексный: нужны и дизайнеры, и аналитики, и разработчики, и тестировщики. Решение настоящих задач развивает навыки командной работы, взаимовыручки и поиска нестандартных подходов.

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

Кажется, что остается только взять реальную бизнес-задачу, собрать команду студентов и настроить процессы. Ребята получают зачеты и опыт, вуз — репутацию, а заказчики наконец-то решают свои проблемы. Шампанское, смех, веселье, все довольны — примерно так я себе это представлял.

Суровая реальность

Думаю, без тега sarcasm понятно, что вышеописанная история воплотилась лишь в моем воображении. За полтора года у меня было четыре проекта, через которые прошли почти пятьдесят студентов. Это весьма неоднозначный опыт: мы сдали один MVP заказчику и еще три канули в Лету.

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

Еще одна интересная задача была посвящена системе управления загруженностью залов и контроля работы преподавателей для танцевальной школы. Такие инструменты, как правило, доступны за деньги. Команда взялась за урезанную, упрощенную, бесплатную версию подобной системы.

Ребята оказались очень толковыми и быстро сделали MVP. Но получив оценку, они полностью потеряли интерес к проекту: внести изменения на основе обратной связи от заказчика стало некому.

Ветряные мельницы

Чувствовал я себя как Дон Кихот, сражающийся с несколькими ветряными мельницами одновременно. Эффективной реализации идеи в основном помешало три причины:

Сложность задач

Про SMART знают все. И про то, что слона нужно делить на маленькие кусочки. Но здесь я сам допустил ошибку: обратная связь от заказчиков повышала сложность задачи, а отказываться было поздно.

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

В очень сложных кейсах приходится менять несколько команд. Нужно тратить время на разъяснения и адаптацию новых ребят, которые будут работать с обратной связью от заказчика. Для них это легаси только создаст проблему, код постепенно наполнится костылями. Задача не будет решена.

Мало мотивированных студентов

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

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

Отсутствие инструментов мотивации на уровне вуза

Для студента главное — выжить. И сосредоточены они при этом на оценках, а не на качестве. Сразу после получения зачета полный энергии и желания творить студент полностью теряет мотивацию. Обещания «в обязательном порядке довести дело до конца, внести все правки в приложение» куда-то испаряются. У вузов в лице преподавателей и других сотрудников нет рычагов давления, способных переломить эту ситуацию.

Что нужно сделать самим студентам, чтобы соответствовать «взрослому» IT

В моем опыте работы в полную силу проявился «закон Мерфи»: все, что можно сделать не так, было сделано не так. Если чего-то не было внесено в требования, то оно не реализовывалось. А даже если все было прописано досконально, то иногда не выполнялось, потому что «забыли обновить страничку», «не посмотрели», «потеряли ссылку».

Все это является барьером при старте работы в настоящем ИТ — стажеры и джуны с таким подходом к работе никому не нужны. Чтобы его преодолеть, студентам необходимо:

• Лучше изучать ИТ-сферу и рабочие процессы в ней. Мои студенты не знали, что делать на дейли и зачем нужны демо. Да, им показывают канбан-доски и рассказывают про спринты, но на практике они не были знакомы с разными типами митингов.

• Учиться не замалчивать проблемы! Это просто ад, и непонятно как с ним бороться. Каждый созвон я начинал с фразы, что нормально чего-то не успевать или не знать. Это стандартная ситуация в IT: важно своевременно предупреждать о проблемах, чтобы я, как руководитель, вообще понимал, что происходит с проектом. Но каждый раз косяки всплывали стабильно в конце спринта. Один раз функциональность не была готова, потому что студенты МОЛЧА просидели над проблемой полторы недели.

• Учиться на результат, а не на оценку. Только так можно получить опыт «взрослой» разработки. Я же видел, что цель студентов — добиться оценок с минимальными усилиями. Периодически это скатывалось в детский сад уровня «а мы не знали, а вы нам не говорили» для каких-то очевидных вещей.

• Не уходить в бесконечный рефакторинг. Да, психологически комфортнее поковырять то, что уже сделано и работает, а не решать новые задачи. Сначала я не видел в этом проблемы и осознал ее только после третьего переделывания основ системы.

• Учиться формулировать свои мысли. Самая ценная и редко находимая роль не разработчик, не тестировщик, не дизайнер, а аналитик. Я так и не смог найти адекватного. Студентам не хватает насмотренности, чтобы самостоятельно прорабатывать функциональность. Были случаи, когда я давал новому кандидату готовую спецификацию, а он пропадал на неделю. В чате писал, что все ок, он уже почти, а потом ПРОСТО ПРОПАДАЛ без объяснения причин.

Позитивные моменты тоже были: в моих проектах принимали участие толковые студенты, которые получили оценки и… правильно — исчезли!

Иллюзия прогресса

Мои ощущения от этого опыта можно описать альбомом The Illusion of Progress группы Staind:

Я оцениваю свой опыт на 3 из 5: были грандиозные планы, на которые я потратил кучу времени, но по факту из всего реализовано только MVP одного проекта. Мне было очень интересно, особенно в начале. У студентов возникали смелые идеи, и они смотрели непредвзято, потому что не имели опыта и не шли проторенными путями.

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

В целом, после нескольких попыток я пришел к двум выводам, как реализовывать подобные проекты:

• Отбирать студентов нужно максимально жестко. Нельзя заставить их сделать то, чего они не хотят — придется искать уже замотивированных. Тем более учитывая, что никаких рычагов давления в вузах нет.

• Проекты надо максимально упрощать, ставить конкретные задачи и договариваться об итоговом и промежуточных результатах с заказчиком.

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