Общение — знайте различные проблемы и способы их решения

Когда я начинал свою карьеру программиста (пока не могу сказать, что я инженер-программист), я думал, что моей главной задачей будет заставить что-то работать. Это не так. Коммуникациябыла огромной проблемой в каждой компании, в которой я работал, и я считаю, что она имеет огромные, недооцененные затраты.

В команде программного обеспечения

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

Использование правильных инструментов для работы

До сих пор я работал в 5 разных компаниях. Крупные (100–500 сотрудников) и более мелкие, которые я видел, растут (8–20 человек). Один общий фактор; Либо они не предоставляют нужных средств коммуникации, либо используют их плохо (если используют вообще). Вот некоторые вещи, которые следует учитывать;

  • Я считаю, что одного только приложения для обмена сообщениями недостаточно для успешного управления отделом разработки программного обеспечения. Он все еще мог работать для очень небольшого экипажа (до 3 человек).
  • Серьезный проект должен рассмотреть какую-то внутреннюю вики. Наличие места для документирования бизнес-логики, архитектурных диаграмм, диаграмм баз данных, целей, заметок о встречах и т. д., а также наличие легкодоступного и доступного для поиска всего этого является ключевым моментом.
  • Держите техническую документацию в коде и README, все остальное должно быть в Wiki.

Интегрируйте документацию в свой процесс

Большинство разработчиков не будут писать документацию, если их об этом специально не попросят. Из-за этого любому, кто не входит в команду разработчиков (которая, вероятно, встречается ежедневно для обсуждения прогресса), становится намного сложнее узнать, что происходит.

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

Повторно используйте контент и ссылки между страницами

Опять же, разработчики не хотят поддерживать базу знаний на 1000 страниц. Вики с повторно используемым контентом / функцией ссылок — это золото. Это означает, что если необходимо сослаться на определенные части документации, ваша Wiki должна предоставить вам инструменты для этого. Это ограничит дублирование, что, в свою очередь, упростит обслуживание и уменьшит количество устаревшей информации.

Периодически сжимайте информацию

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

Наконец-то… серьезно относитесь к именам переменных

Некоторые разработчики очень специфичны в именах своих переменных, другие довольно вольны. Документация также находится повсюду в коде. Каждая строка — это инструкция о том, как работает программа, это важно. Просмотр имен переменных (как бы тривиально это ни звучало) — важная часть процесса контроля качества.

По всей компании

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

Общение является двунаправленным

Теперь, когда вы решили проблемы с документацией и коммуникацией в вашей команде разработчиков, пришло время оценить эту информацию. Убедитесь, что информация течет в обоих направлениях. Слишком часто команда разработчиков кричит у подножия горы, в то время как менеджеры витают в облаках, измеряя 2000 различных KPI и ничего не слыша.

Ваши менеджеры должны быть очень близки к команде разработчиков программного обеспечения, понимать их потребности и их решения и немного отпускать свою власть для общего блага. Хороший менеджер согласится пойти по длинному пути, чтобы сэкономить деньги в долгосрочной перспективе. Плохой попросит вас поторопиться, пока есть что-то, что хоть как-то работает к установленному сроку. Их KPI будут выглядеть хорошо, но проект будет стоить в 10 раз больше, чем предполагалось.

Кто за что отвечает

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

  • путать людей;
  • разозлить руководство («вы не выполняете свою работу»);
  • Люди работают над одним и тем же

Всем нужно общее видение

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

В любом случае. Это была моя красивая напыщенная речь об общении, дайте мне знать, что вы думаете!