Я работаю разработчиком встраиваемого программного обеспечения в растущей компании, которая производит физические продукты и, по моему мнению, испытывает некоторые трудности из-за своего быстрого роста. На протяжении десятилетий это была довольно маленькая компания, в которой работало всего несколько десятков инженеров по всем дисциплинам, а не только по программному обеспечению, и она выпускала относительно небольшое количество продуктов.
Модель разработки продукта, которой обычно следовали, заключалась в том, чтобы собрать команду инженеров из каждой области (программное обеспечение, электрика, механика, маркетинг, производство и т. д.), а затем команда работает над выпуском продукта в гибкой манере. По крайней мере, так это должно работать в теории.
На самом деле работа очень разрозненная, поскольку я, как инженер-программист, не могу обновлять модели САПР или компоновать печатную плату, и точно так же другие мои коллеги по команде не имеют ни малейшего представления о том, как писать программное обеспечение. Вместо сплоченной команды это становится своего рода группой из одного человека, каждый из которых занимается своей конкретной дисциплиной и проверяет отчет о состоянии во время наших стендап-совещаний.
До недавнего времени не существовало реальной общей модели программного обеспечения, каждый проект, по сути, разветвлял кодовую базу аналогичного продукта и вносил любые модификации, необходимые для разрабатываемого продукта. Как и ожидалось, это привело к множеству разрозненных вариаций очень похожих реализаций, но некоторые разработчики приложили больше усилий для создания общей библиотеки для смягчения этой проблемы.
Большинство разработчиков согласны с тем, что это направление, в котором мы должны двигаться, но у каждого есть свое представление о том, как это должно быть достигнуто, и нет никакого мандата на тот или иной путь, поэтому из этого никогда ничего не выходит. В частности, есть одна внутренняя библиотека, созданная и поддерживаемая старшим разработчиком, которая является наиболее многообещающей и широко используемой, но некоторым другим разработчикам не нравится ее архитектурный стиль, поэтому они не используют ее. Этот старший разработчик также находится в другом отделе исследований и разработок, отдельном от разработки продуктов, где работают я и другие разработчики продуктов, поэтому он также не имеет полномочий издавать какие-либо полномочия.
Наш менеджер по программному обеспечению долгое время не занимался реальной разработкой и является скорее менеджером по персоналу, а не настоящим техническим руководителем, а фактические руководители продуктов обычно приходят из других дисциплин, а не из программного обеспечения, поэтому их глаза, как правило, стекленеют, когда какое-либо программное обеспечение возникает разговор. А поскольку за каждым продуктом обычно закреплен только один разработчик программного обеспечения, нет особой ответственности за поддержание какого-либо последовательного стиля или архитектуры.
Количество продуктов, которые мы разрабатываем, а также их сложность значительно выросли всего за последние несколько лет, и я чувствую, что мы находимся в опасной близости от обрыва катастрофы, если наша текущая модель останется такой, какой она была.
TLDR : у нас есть около дюжины персональных выставок программного обеспечения в одном и том же отделе без каких-либо конкретных указаний о том, как должно быть структурировано наше программное обеспечение.
Как я могу лучше всего выступать за лучшую организацию, в которой группы разработчиков программного обеспечения более сотрудничают и менее разрознены? Некоторые из нас предложили, чтобы команда разработчиков программного обеспечения занималась проектами как единое целое, вместо того, чтобы иметь только одного разработчика для каждого продукта, но текущий метод организации управляется с уровня вице-президента, и я не уверен, что мой собственный менеджер программного обеспечения даже имел бы полномочия сделать такое изменение, даже если бы он хотел.
Я работаю в компании всего несколько лет, поэтому я не уверен, что я лучший человек, чтобы предлагать такие радикальные изменения процесса, но в то же время я чувствую, что можно было бы так много улучшить с правильной структурой в место.
Вы упомянули, что ваш менеджер не слишком техничен, так что это была бы хорошая возможность для кого-то из команды проявить себя. Похоже, у вас есть интерес и некоторые идеи, так что, возможно, вы можете взять это на себя. Вы, вероятно, захотите предупредить своего менеджера, но на данном этапе не нужно слишком вовлекать его или ее. Активизируясь и беря на себя инициативу, хороший менеджер оценит тот факт, что вы заботитесь и что вы взяли на себя инициативу, чтобы помочь улучшить команду и компанию, особенно с учетом того, что вашему менеджеру может не хватать технических знаний для этого. лично.
Первый шаг — провести исследование и обобщить результаты. Определите проблемы, как вы их видите, и объясните, как они негативно влияют на компанию. Для растущей компании это совершенно нормально, так что ищите другие примеры и тематические исследования, подтверждающие ваши утверждения. Далее вам нужно придумать возможные решения. Будьте внимательны в объяснении затрат и выгод. Обратите внимание, что вы можете включить сюда членов вашей команды, так как похоже, что у них тоже есть идеи, как по проблемам, так и по решениям. Просто обязательно сосредоточьтесь на вещах и не позволяйте этому отвлекать.
После того, как вы определили некоторые проблемы и потенциальные решения, которые можно принять, я рекомендую превратить это в презентацию. Запланируйте встречу с вашей командой (включая менеджера). Цель этой встречи: а) получить обратную связь и б) собрать всех на одной волне. По завершении этой встречи очень важно, чтобы вы начали планировать, как реализовать согласованные изменения и сроки для этого. Если вам нужно одобрение вышестоящего руководства, тогда вам понадобится помощь вашего менеджера. На данный момент вы проделали работу, чтобы помочь своему менее техническому менеджеру и, надеюсь, дали ему инструменты, необходимые для того, чтобы сдвинуться с мертвой точки.
Последнее, что нужно сделать, это убедиться, что то, что вы решили как команда, действительно реализовано. Скорее всего, будут вещи, которые вы и члены вашей команды сможете решить немедленно, и другие, которые могут потребовать более крупных изменений/покупок и т. д., требующих помощи со стороны руководства. Я рекомендую организовать повторяющуюся встречу, чтобы проверить прогресс и выявить любые препятствия, которые могут вам мешать. Последовательность и подотчетность являются ключом к успешному внедрению этих новых процессов.
И последнее замечание: если вы чувствуете, что проработали в компании недостаточно долго, чтобы заняться этим лично, его можно применить к старшему члену команды или взять на себя всю группу. Настройте в соответствии с вашими потребностями.
Проявите инициативу, найдите и устраните одну повторяющуюся проблему, с которой сталкивается команда.
Вы говорите, что все разработчики согласны с тем, что текущий способ ведения бизнеса не работает, но никто не согласен с тем, что делать. Вам нужно найти одну вещь, которая была повторяющейся проблемой, и реализовать решение.
Поговорите с другими разработчиками, которых вы знаете, и пригласите как минимум 3 или 4 из них присоединиться к вашему плану. Затем выполните свой план. Как только это будет сделано, сообщите об этом остальным членам команды и вашему боссу.
Когда вы рассказываете людям, что вы сделали, сосредоточьтесь на том факте, что вы тратите время впустую из-за плохого процесса. Что-то вроде...
После того, как я пропустил событие/крайний срок XYZ, я решил исправить эту проблему. Проблема со вставкой поставила меня в очень затруднительное положение, когда мне пришлось пропустить важное жизненное событие/крайний срок. Я действительно хотел бы услышать, что все думают об этом решении.
Стрейдер
Дэн
Стрейдер
Дэн
Мог говорит восстановить Монику