Введение

Много конкурсов на свете для программистов, есть среди них такой конкурс- Microsoft Imagine Cup. Все программисты уважают олимпиадников и олимпиады acm, но чтобы в них участвовать, нужны очень серьезно готовиться, решать специфичные задачи. Уверен, многие программисты просто работают и решают задачи далекие от нахождения пути конем куда-нибудь, зато создают софт, за который платят. Microsoft imagine cup- это как раз тот конкурс где можно проявить наши навыки программирования, придумать идею, получить опыт работы в команде, получить великолепный опыт в новых областях программирования и при этом не обязательно знать разницу О большим и Омега большим.

Я 3 года участвовал в этом конкурсе в свободное от работы время, 2 раза в качестве члена команды своего вуза и 1 раз в качестве ментора команды вне моего вуза. Хочу поделиться опытом, который я получил во время конкурса.

Предостережение

“Красная или синяя таблетка?”. Я не обещаю что будет легко быть участником ImagineCup или ментором, но я обещаю что будет интересно! Вы можете получить такой опыт, которого нигде более не получите, а опыт полезный. Если Вы не готовы преодолеть трудности, закройте страничку...

Зачем участвовать?!

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

1. На работе как правило работаешь над одним проектом довольно долго, и рано или поздно он начинает надоедать. Необходимо разнообразие. Во время последнего конкурса на работе я занимался ассемблером и C# и wpf, но мне оно было не очень интересно, куда более интересны были поисковые системы, алгоритмы поиска (не путать с поисковой оптимизацией), создание сервисов. Участие в конкурсе - отличный способ написать что-то полезное в интересной для себя области, а не тупо повторять примеры из книжек.

2. Во время конкурса всегда работаешь в команде, так или иначе. Командная работа- это то чему я не научился за 2 предыдущих года на работе, потому что работали мы всегда по одному, а система вузовского образования так вообще почти на 100% построена на индивидуальной работе. Видели ли вы что то большое, что создал в 20 веке всего один человек? Даже Эйнштейну помогала его жена математик, не говоря уже о космической программе, над которой трудились тысячи специалистов. Командная работа- это круто!

3. Вы получаете опыт, который вы не получите более не где, потому что на работе так или иначе, мы исполнители. Задачи ставят заказчики с аналитиками, далее тимлиды и архитекторы придумывают как это сделать, а далее спускаются задачи на сотрудников уже разжёванные и пережеванные, осталось только проглотить. Фантазия очень ограничена. Когда же ты сам придумываешь идею проекта, как реализовывать, то даже если ты еще студент или младший разработчик(junior) ты начинаешь задумываться о серьезных вещах, о которых ранее даже не переживал.

4. Общение с людьми вовне. “Каждый чемпион в своем дворе, а выйди на район!” Я все доказал в своей группе, затем в вузе. Потолок. Когда ты достиг много на своем уровне, то расти дальше можно только вовне, внутри целей нет. Международный конкурс с локальными финалами - вполне подходит. В вузе так или иначе привыкаешь к ситуации, ничего не боишься, а вот выходишь на конкурс и все, робеешь. Перед тобой сотня незнакомых людей, которым плевать на твои успехе в матанализе предыдущие. Они будут оценивать тебя здесь и сейчас, по тому, что ты им сейчас продемонстрируешь. По личному опыту скажу, что страшно. “Те кто говорит что ему не страшно, либо врет либо ему пора к доктору” (с). А еще на таких конкурсах много программистов приходит, можно пообщаться с сотрудниками Microsoft, которых не так уж часто видишь. На самом деле я могу придумать еще причин, но оставлю это читателю.

Кто такой ментор?

Честно я до сих пор не знаю точного ответа на этот вопрос. Официального положения, определения я не видел, да и сотрудники ms отвечают по разному. Я за свои 3 года опыта видел 2 менторов в своей команде, сам был ментором и видел другие команды, общался с ними. Тут я попытаюсь суммировать то, что видел.

Менторы бывают разных типов, это зависит понятно дело от человека, команды и обстоятельств.

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

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

   2. Еще одна категория ментора - старик-советчик. Этот человек имеет опыт, которого нет у остальных и по первому требованию им делится, но при этом пальцем о пальцем не ударил, чтобы в репозитарии кода появилось что-то. Вполне себе хороший ментор пришедший из научной реальности. Ты делаешь, а научник направляет, работа то твоя!

Все эти категории менторов объединяет одно - хорошая самоорганизация команды. Но это бывает редко. Я когда стал ментором, наслушался сказок agile, scrum, самоорганизующиеся команды. В общем меня реальность жестко ”фейсом об тейбл” стукнула. Самоорганизация даже при высокой мотивации очень сложно, когда люди первый раз в жизни делают проект на четверых общий и при этом студенты 2-3 курсов. Первый раз я это увидел еще пару лет назад, когда наш научник и ментор неделю нас не трогали, мы забили на проект, хотя очень старались и хотели выиграть и чуть не прошляпили подачу заявки. Второй раз это было уже когда я был ментором. Поначалу я был ментором-членом команды, но потом пришлось забыть эти сказки про самоорганизацию и более серьезно заняться командой уже не в качестве одного из, а некого организующего звена, потому что когда я заболел на неделю, я обнаружил что в репозитарии за неделю ни единого комита и ни единого письма или звонка по проекту не было, на следующей skype встречи узнал, что ни кто ничего и не делал, хотя команда была хорошо мотивирована. В общем я так родился четвертый тип ментора о котором я расскажу несколько больше, тк сам им был

1. Ментор - организатор. Говорят, что любой проект в ит - это не проект в ит как таковой тк накодить и внедрить можно что угодно, а вот убедить людей это использовать и сделать так, чтобы разработчики не убили друг друга - это куда сложнее. После определенного момента я перестал программировать, так как времени на все не хватало. Я стал заниматься организацией работы, давать советы, проводить встречи по проекту, кому-то книги по windows phone7 давать, кому-то показывать как работать с Entity Framework и WCF, пытался весь негатив команды переключить на себя, чтобы на сцене была таки команды а не 4 личности. Кто-то может сказать- это обычный менеджмент… Возможно. Но не нравится мне слово менеджмент! У меня оно ассоциируется, либо с некомпетентными людьми, которые после 2 месяцев проекта не знают что у них проект на asp.net mvc пишется, а не на webforms, либо с “ребятишками” из всяких магазинов, которые поддержат любой ваш выбор, не разбираясь в сути дела, но всегда посоветуют самый дорогой вариант, как лучший. Мне нравится скорее слово ментор, team leader, да хоть project owner или scrum muster, благо все эти функции приходилось выполнять.

Команда:

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

Кого брать в команду - вопрос интересный, тут сейчас любой специалист отдела кадром мне может лекцию прочесть! Но вот незадача, искать человека по объявлению или хантить человека еще где-либо на работу за деньги - это одно, а искать студентов умеющих программировать из одного вуза со скорее всего своего факультета с одного или двух потоков, для участия в конкурсе за бесплатно – это другое, очередь строиться не будет.

Все не то, чем кажется. С другой стороны не понятно кого звать в команду? В нашу команду попал олимпиадник acm, я обрадовался! УРА, будет кому алгоритм поиска, работу с поисковым движком писать, дело в шляпе! А фиг там! За время работы человек написал строк 15 кода и то метод со switch на 3 варианта с бряками, немного занялся бумажками, а потом никому не сказав устроился на работе и по сути исчез. С другой стороны в команду мы всегда брали девушку, которая ограждала программистов от бумаги, но если не писать тонну бумаги она не сильно помогает. В случаи, когда я был ментором, девушка, которая должна была своим платьем прикрыть наши косяки и огородить от бумаги, неожиданно открыла в себе интуитивный талант верстки, работы над дизайном, юзабилити и просто оказалась беспредельно полезным человеком для команды. В итоге на кого надежды возлагаешь, может не сделать ничего, а в том от кого не ждал, может открыться истинный талант.

Как придумать идею? Согласно идеализму - идея первична. Идея поднимает целые народы. Миллионы людей в нашей стране строили социализм. Идея была великая! (что случилось потом - не тема разговора). Посмотрите фильмы или спросите у дедов и прадедов своих - За Родину, люди на амбразуру ложились, на танки шли в рукопашную.

На самом деле идей много вокруг, вопрос в том чтобы взять их и сделать. В случаи нашей команды это было просто, собрались мы в кофе, я рассказал про цели конкурса, про критерии оценки, и рассказал все проекты, который я видел ранее за 2 года. И далее мозговой штурмом. 2 идеи с человека, меньше нельзя больше легко, чья идея победит тому скидываются на пирожное (пиво, пицца, в общем, по обстоятельствам). Идей рождается обычно по началу немного… 2-3. А потом начинается шквал. Как проводить мозговые штурмы, решать задачи методом Дельфи и тп думаю рассказывать не надо, это не цель моего рассказа. Как идеи фильтровать, записывать, выбирать, делать так, чтобы одни идеи не давили другие и еще многое другое- это то, что скорее надо чувствовать, чем следовать инструкции. Не бойтесь! У нас была идея даже решить реально глобальную проблему. Чтобы можно было найти второй носок прикрипить к нему маячок как в магазинах. Идеи могут быть безумные, сформировать сначала массив 10-15 идей и далее пропустить через воронку фильтрации. Грубый фильтр, средний, тонкий. И главное, не забывать о цель конкурса. Реализация важна конечно, но главное на конкурсе все таки идея, как сказали нам- единственно, что не хватило моей команде для победы- “Эффект ВАУ”, все остальное было образцово-показательным. ИДЕЯ ПРАВИТ МИРОМ!

Суть идеи

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

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

Microsoft Imagine Cup, опыт участия и менторства. Часть 3