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

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

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

2016 Hellow, World!


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

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


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

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


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

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


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

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


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

Ревью


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

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

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

Заключение


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

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

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

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

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

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

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

Категории

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

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru