Привет! Меня зовут Максим Павлов, я студент Технопарка. В этой статье я хочу донести идеи, которые извлек из разработки учебных проектов командой начинающих программистов. После каждого проекта я стараюсь оценить, что нового я вынес из него. Написано много статей про управление проектами в больших и маленьких компаниях. Читая их на Хабре, я всегда примеряю идеи, высказанные там, на нашу команду. Но все-таки, у учебной команды есть очень важная специфика.
- Мотивация. Вся команда строится только на мотивации и полном доверии. В компаниях люди держатся по многим причинам: деньги, авторитет руководителя, интересность проекта, значимость делаемой работы. Ни одна из этих причин, кроме интересности проекта, не удержит человека в учебной команде.
- Учеба. Главная боль всех учебных команд — это учеба в университете. У кого-то она сложнее, у кого-то проще. У кого-то интереснее, у кого-то скучнее. Но, к сожалению, в рамках работы над проектом в Технопарке очень часто приходится слышать ключевые словосочетания «курсач горит», «РК завтра», «у меня лаба».
Эти пункты вносят свою специфику в управление учебным проектом. Я не видел ни одной статьи о работе в студенческих группах, поэтому хочу поделиться своим опытом.
Идеи
Есть ребята, которые все думают о том, что бы такое написать. После истории с Пикабу (ссылка на наш первый пост о приложении на Пикабу внизу) я понял, насколько важно быть постоянным членом большого сообщества. Например, на том же Пикабу каждый день появляются разные лайфхаки. Там же мы и почерпнули идею нашего приложения. Второй плюс — сообщество уже будет готово к вашему сервису. И люди будут знать, зачем он, если вы пишете приложение на тему поста, который набрал достаточно «плюсов» от сообщества.
С чего начать?
По итогам трех семестров могу сказать, что самым удачной схемой для изучения новой технологии/языка была двухэтапная схема. Сначала пишется большой и сложный проект (к сожалению, не доделывается с первого захода или вообще не заканчивается), вторым шагом делается маленький и простой проект. У меня в двух случаях из двух он оказывался успешным. Наш первый «большой» проект со своей серверной частью и монгой мы писали в течение всего семестра. И, я уверен, что мы его закончим.
Команда сделала
Если вам повезло так же как и мне, и в среднем каждый член команды пишет примерно одинаково кода, то никогда не прибегайте к мотивации или оправданиям из разряда «ну я же больше тебя писал тесты». Разумеется, это не относится к случаям, в которых ты в течение месяца один пишешь проект, а остальные «вот-вот подтянутся». Несколько случаев помогли мне осознать, что вся работа в рамках команды сделана командой, а не отдельным человеком. С одной стороны, это не дает развиваться эгоизму, а с другой — ты знаешь, что даже если ты вдруг заболел или тебе пришлось срочно уехать, то команда продолжает писать. Попробуйте посмотреть это видео. Нам понравилось. :)
3 человека
Я знаю и уважаю людей, которые отлично работают вдвоем, но, в моем понимании, это гениальные сверх-люди. Моя статья для таких обычных людей, как я.
Я на своей шкуре убедился, что 3 человека — это идеал. Своих двух людей я нашел по моему любимому принципу: по результатам. С ними я первый раз приблизился к пониманию понятия «Dream Team». У них была почти дописанная игра, оба сделали неплохие игрушки (по меркам нашего семестра) на курсе Front-End-a, оба получили отличную оценку по БД. К своим заслугам на тот момент я мог отнести только доделанную в аврале за две недели игру по курсу Java и джойстик для самолетика по фронтенду. Почему 3? У каждого (серьезно, каждого) был момент, когда он в силу зависящих или не зависящих от него обстоятельств отключался от разработки. Но команда продолжала работать.
Как удобнее?
В любом продукте есть задачи, которые очень надо решить, но которые совсем не связаны с разработкой. Очень много времени нам сэкономили наш дизайнер Паша и генератор идей Игорь. Кто знает, сколько бы мы потратили на споры куда лучше поместить элементы, что бы такого интересного еще добавить в приложение, поиск аргументов, обиды, если бы не было этих двух людей. Поэтому я для себя решил, что все решения, связанные с usability и дизайном, должны приниматься одним человеком, а новые нестандартные фичи придумываться другим. Причем оба должны не участвовать в написании кода. Кроме того, идея еще одного нашего приложения, которое еще ожидает своего звездного часа, принадлежит целиком Игорю. Если все как мы верят в дизайнерские способности человека-дизайнера и идеи человека-генератора, то не будет конфликтов и обид из-за отвергнутых идей и решений, принятых не в твою пользу. Если у вас нет знакомого дизайнера, вспомните, кто из ваших друзей заканчивал художку, посмотрите его работы и назначьте его главным по дизайну. Пусть только он будет решать, что и куда размещать, как и что должно функционировать. Этот шаг позволит вам тратить время только на разработку. Если в итоге проект взлетит, а дизайн вас не будет устраивать — скиньтесь и закажите дизайн у другого дизайнера. :)
Мотивация
Иногда мотивации действительно не хватает. У меня есть парочка способов мотивации, проверенных в бою.
- Друзья. Рассказать об этом в красках максимальному количеству друзей. Когда все твои друзья знают, что ты пишешь приложение, то они не дадут тебе слиться, потому что будут скептически спрашивать: «ну что, как приложение? Уже выложили?» Когда много людей знают, уже нет возможности слиться.
- Конкуренты. После прочтения одной замечательной книги я понял, что конкуренты нужны, потому что именно они дают тебе мотивацию делать твой продукт еще лучше. В нашем случае на четвертый день разработки появилась поделка без нормально дизайна и функционала. Мы были уверены в том, что у нас нормальный дизайн и пара киллер-фич, которых не было в том приложении. Например, просмотр профиля Вконтакте прямо внутри приложения и добавление в закладки (Wishlist). Ну, и главное, нам нужен был хотя бы один законченный проект в портфолио. Так что конкурент нас только усилил и заставил писать быстрее. Главный принцип, который я вынес — не надо отчаиваться, если у вас появились конкуренты. Если твой продукт круче, то ты обязательно вытеснишь продукт, который пришел раньше, но, по сути, хуже.
Todo-list
Этот пункт относится скорее к тому, чего у нас не было, но очень не хватало. Теперь я понял, насколько важно определить список фич до первой выкладки и первого анонса. Без такого списка оба эти пункта могут откладываться на неопределенный срок. Так получилось, что первая выложенная версия приложения была глючной. Рекомендация — расскажите друзьям, которым вы до этого рассказывали о проекте, о том, что вы выложились. Чем больше людей об этом узнают, тем лучше. Поток баг-репортов и пожеланий даст дополнительную мотивацию и поможет определить список фич, которые надо пофиксить к анонсу. И по себе скажу, корявое приложение в Google Play — сам по себе неплохой мотиватор.
Что дальше?
Вы написали приложение, выложили, оно кое-как работает, иногда падает. Что делать дальше? Разрабатывать новые фичи или оттачивать до совершенства уже готовые? Наш однозначный ответ на этот неоднозначный вопрос — что нравится, то и делай! «Тут не каторга» и не огромная компания. Делая то, что нравится, ты делаешь это намного лучше, чем то, что не очень нравится. А насчет плохо работающего текущего функционала: в один момент наберется критическая масса кода, который надо отрефакторить. И найдется человек, которого это достало больше всех. И опять он будет замотивирован сделать свою работу хорошо, потому что так дальше жить нельзя.
Сроки
Один раз на кафедре ИУ6 на курсе по управлению производством выступал менеджер из компании, которую нельзя называть. Он рассказал о своем методе оценки сроков проекта на основе представлений разработчиков. «Обычно разработчик ошибается на единицу измерения. То есть, если он говорит, что сделает за 3 дня, значит ± 1 день». Так и получилось. В начале проекта я рассчитывал, что втроем мы сделаем это не больше, чем за неделю. Мы делали это ровно 2 недели. День в день. Так что впредь так мы и будем оценивать свою работу. Буду рад, если вы поделитесь своим опытом оценок сроков.
P.S. Посмотреть, что у нас уже получилось можно по этой ссылке. Первый анонс на пикабу по этой ссылке. Будем очень рады скачиваниям, хорошим оценкам, предложениям и замечаниям.
Автор: uwriter
