Русский
Русский
English
Статистика
Реклама

Опыт в управлении разработки некоммерческого проекта или как убить нервную систему

Многие на ранних порах знакомства с программированием выбирают напишу своё, вместо участия уже в чьём-то проекте. В принципе, этот выбор весьма понятен, т.к. никакой критики, рамок и кодревью от олдов, ИМХО. Со временем, конечно, выбор меняется, но бывают и исключения. Об одном из них и пойдёт речь.

2016 Hellow, World!


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

Более опытный участник


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

Первые успехи первые участники


Успехи идёт рядом с интересом, поэтому какое-то время будет поток людей, желающих поучаствовать в разработке. Моей первой ошибкой стал выбор приоритета количества, а не качества такой помощи. Что и привело к большому количеству багов, которые исправляли и исправляем с 2017 по сей день. Со временем, народ отсеется сам, в хорошем случае останутся пару человек, которые будут иметь по прежнему хоть какой-то интерес к этому. Вторая ошибка была в попытках удержать оставшихся людей, а не развивать проект в выбранном направлении, что превратило его в песочницу. Разный кодстайл, постоянные споры в команде, отсутствие единой идеи и хоть какого-то руководства. Каждый участник тащил одеяло в свою сторону. Из ситуации получилось выйти, убрав всех, кто слишком сильно пытался настаивать на своём. Таким образом более спокойные участники стали более податливыми, что позволило более-менее стабилизировать ситуацию. Но, не всё так хорошо Последствия происходящего убили практически весь интерес коммьюнити к проекту, что и возвращает нас к первому пункту нашей статьи. Нужно сделать что-то стоящее.

Форки, форки и ещё раз форки


Следующая проблема это соседние форки. Проект был OpenSource, поэтому всё интересное утекало из него в соседние проекты, что привело к проблеме уникальности. Решением стала переработка базового API, для усложнения переноса правок. Конечно, любой, кто более-менее разбирается в языке и API движка, мог перенести нужный код, потратив n-ное количество времени, на изучение изменений. Но всё же часть форков не стала с этим мучатся.

Ушёл по английски


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

Ревью


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

  • Отсутствие единого стиля
  • Ошибки, баги, исключения
  • Отсутствие контроля контента

Причём, желательно, чтоб ревью проводилось несколькими людьми, думаю и так понятно почему

Заключение


Итак, повторю вкратце всё сказанное выше: выбирайте качество фичи, а не их количество. Следите за тем, что попадает в master. Не пытайтесь удержать в команде тех, кто создаёт больше проблем, чем контента.
Источник: habr.com
К списку статей
Опубликовано: 19.06.2020 00:04:04
0

Сейчас читают

Комментариев (0)
Имя
Электронная почта

Управление разработкой

Руководство командой

Руководство для новичков

Руководство проектами

Категории

Последние комментарии

© 2006-2020, personeltest.ru