Я присоединился к этой небольшой компании пару лет назад, в которой на данный момент работает менее 10 человек. Основной продукт — SAAS-приложение, клиентская база которого стабильно растет. Основатель и генеральный директор кодировал большую часть кода с нуля сам, время от времени прибегая к помощи наемных работников. Я глубоко уважаю то, что он до сих пор сделал с бизнесом, я не встречал столько людей, столь же целеустремленных, как он.
Затем меня наняли в качестве опытного разработчика на должность технического руководителя с целью повысить уровень качества и улучшить организационную масштабируемость с точки зрения кода, чтобы мы могли взять на себя больше разработчиков, которых у нас уже есть, и вскоре надеюсь даже больше. До сих пор я ввел контроль версий, тестирование и попытался модернизировать и установить некоторый уровень стандартов и руководств по кодированию вместе с моей командой, которая работает довольно хорошо, все еще с определенными возможностями для улучшения, но на правильном пути. Для меня проблема в генеральном директоре. Он самоучка, не то чтобы это было проблемой само по себе, но он не приобрел никаких навыков программирования дальше, чем базовые учебные пособия низкого уровня, специфичные для технологии, которую мы используем. По причинам, которые я бы никогда не оспаривал, он мало времени проводит в офисе, в основном выполняя управленческие задачи, как он определенно должен. Он уходит рано или работает несколько дней полностью, а затем часто тратит время на кодирование в нерабочее время. В основном он берется за новые идеи или конкретные функции, запрошенные отдельными клиентами, и добавляет их прямо в производство, минуя наши обычные процедуры, как если бы он все еще был единственным разработчиком, не заботясь о стандартах, о которых он всегда говорит очень положительно. Его работа иногда приводит к проблемам, которые возникают у меня и моих товарищей по команде, или просто новые функции, которые мы не знаем, как они должны работать, потому что у нас нет времени разбираться, а когда его нет рядом, мы тратим лишнее время на вопросы клиентов. о них. В основном он берется за новые идеи или конкретные функции, запрошенные отдельными клиентами, и добавляет их прямо в производство, минуя наши обычные процедуры, как если бы он все еще был единственным разработчиком, не заботясь о стандартах, о которых он всегда говорит очень положительно. Его работа иногда приводит к проблемам, которые возникают у меня и моих товарищей по команде, или просто новые функции, которые мы не знаем, как они должны работать, потому что у нас нет времени разбираться, а когда его нет рядом, мы тратим лишнее время на вопросы клиентов. о них. В основном он берется за новые идеи или конкретные функции, запрошенные отдельными клиентами, и добавляет их прямо в производство, минуя наши обычные процедуры, как если бы он все еще был единственным разработчиком, не заботясь о стандартах, о которых он всегда говорит очень положительно. Его работа иногда приводит к проблемам, которые возникают у меня и моих товарищей по команде, или просто новые функции, которые мы не знаем, как они должны работать, потому что у нас нет времени разбираться, а когда его нет рядом, мы тратим лишнее время на вопросы клиентов. о них.
Я понимаю, что мы растем и должны достичь более высокой прибыльности, но определенно кажется, что он гонится за краткосрочными низкими баллами, чтобы получить крутых или крупных клиентов, которые могут окупиться или не окупиться, и говорит, что мы (сотрудники разработчиков) исправим и очистим позже, но вместо этого становится множеством мелких головных болей, над которыми у нас все равно нет времени работать, потому что всегда есть что-то более важное.
Я попытался рассказать о своих проблемах с этим своему боссу и соучредителю продукта, и они ответили согласием и пониманием. Но во время нашей последней оценки сотрудников я действительно получил обратную связь, что я «должен иногда пытаться выполнять задачи быстрее, вместо того, чтобы пытаться найти наилучший возможный способ», но также и то, что они впечатлены качеством моей работы в целом. Я согласен с тем, что вы не можете тратить так много времени на каждую задачу, и я принимаю предположение, что у меня может быть узкая точка зрения, но в то же время я верю, что генеральный директор не знает о методах разработки и не имеет теоретического понимания. архитектуре программного обеспечения или даже больше, чем очень простая объектная ориентация, что делает эту обратную связь немного трудной для понимания.
Я начинаю думать, что не подхожу для этой компании. Я знаю, что у меня есть технические навыки, но я думаю, что мне не хватает более мягких навыков, необходимых для того, чтобы быть техническим руководителем в организации такого типа, которой я должен был и хотел бы быть. Я просто не понимаю, как я могу подойти к этому без пренебрежительного отношения, потому что мне кажется, что я уже пишу это. Я, наверное, немного расстроен из-за того, что чувствую, что становлюсь хуже разработчика из-за этой ситуации.
Не пора ли двигаться дальше и найти возможность развивать эти навыки в более благоприятной для меня среде? Или есть лучший способ справиться с чем-то вроде этого?
Это очень распространенная проблема в небольших магазинах; Когда-то я сам создавал такие же проблемы, запуская запуск программного обеспечения.
Ключом к ее решению является образование. Независимо от того, заинтересован ли ваш генеральный директор в том, чтобы стать разработчиком большого D, если он знакомится с идеями, касающимися качества кода, что такое модульное тестирование и почему оно важно и т. д., он поймет это и, в конечном счете, обратится к вам за лидерством. .
Один из способов обучить его — приглашать его на технические конференции для полиглотов, такие как CodeMash или That Conference , и побуждать его «вернуться с новыми идеями о том, как мы можем улучшить качество нашего кода». Еще лучше: пойдите с ним и поднимите вопрос о том, как не выпускать плохое программное обеспечение, с другими на конференции, пока он рядом.
Еще один хороший вариант — пригласить местную техническую консалтинговую фирму и устроить ланч по этой теме. Большинство будет делать такие вещи бесплатно и (бонус!) может настаивать на присутствии босса, поскольку именно так они получают продажи. (В этом случае вам следует бросить это как намек консалтинговой фирме: «Пожалуйста, убедитесь, что наш генеральный директор присутствует; ему действительно нужно это услышать».) Большое преимущество консультантов в том, что они являются независимой и заслуживающей доверия третьей стороной, которой платят. говорить правду власти, что и нужно в данном случае. (Отказ от ответственности: в настоящее время я работаю в консалтинговой фирме.)
Что касается отзывов, которые вы получили о скорости и «наилучшем возможном пути», вы можете указать, что существует существенная разница между «просто выпустить это» с отсутствующими некоторыми функциями и «выпустить это СЕЙЧАС!» с ошибками, которые разочаровывают и злят пользователей. Если он узнает о связи между качеством программного обеспечения и довольными клиентами, он с большей вероятностью поддержит то, что вы пытаетесь сделать.
Если генеральный директор вообще доступен, он должен быть полностью открыт для этой обратной связи. В конце концов, он назначил вас техническим руководителем, поэтому, если вы решите, что необходимо соблюдать определенные стандарты и что его вклад не соответствует этим стандартам, вы должны сообщить ему об этом.
Если вам нужен «самый мягкий» способ сделать это, который не создает впечатление, что вы выделяете его, я бы ввел обязательные проверки кода для всего зафиксированного кода (если вы действительно этого еще не делаете). Убедитесь, что вся работа отправляется через PR, а не напрямую в основную ветку разработки, а затем всякий раз, когда кто-либо отправляет PR (вы, ваш джуниор, генеральный директор и т. д.), назначьте кого-то другого для проверки этого кода на соответствие задокументированному качеству кода. & правила стандартов перед утверждением. Многие системы позволяют вам применять это, чтобы запретить прямую фиксацию в основной ветке.
Конечно, если генеральный директор говорит «нет» или обижается, когда ему говорят, что его код не соответствует требованиям, у вас не так уж много вариантов — он босс. Если вы решите искать работу в другом месте, хорошая новость заключается в том, что вы можете сделать это в удобное для вас время. Такой стиль кодирования с большей вероятностью вызовет проблемы в среднесрочной и долгосрочной перспективе (технический долг), поэтому нет необходимости немедленно устранять проблему, как это может быть в случае более крупных проблем.