То, что я узнал так далеко, когда я впервые работал техническим руководителем

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

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

Я собираюсь поделиться некоторыми важными уроками, которые я усвоил на данный момент, которые могут помочь некоторым из вас в будущем занять позицию технического руководителя. Те из вас, кто уже находится в этом положении, я надеюсь, что некоторые из моих уроков заставят задуматься.

Вездесущий язык

Нет ничего хуже, чем пытаться что-то кому-то объяснить, и как бы вы ни перефразировали предложение, сообщение просто не доходит до вас. Исторически сложилось так, что я неоднократно сталкивался с этой конкретной проблемой, и мне особенно не удавалось правильно сформулировать свои мысли. Это была первая важная ступенька, которую мне пришлось преодолеть.

Первое, что я узнал, - это концепция повсеместного языка. Это просто означает согласованную терминологию, используемую для описания системы. Часто это делают эксперты в предметной области, такие как владелец продукта, ведущий разработчик, заинтересованные стороны и т. Д. Любой, кто досконально знает, как должна функционировать система. Это необходимо для устранения разрыва между техническим языком и деловым языком, облегчая общение по всем направлениям.

Как только это было установлено, я обнаружил, что объяснять что-либо о системе становится значительно проще. Использование одного и того же языка позволяет избежать неверных толкований и никого не отталкивает от часто важного разговора.

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

Понимание требований бизнеса / клиентов

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

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

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

Понимание всего решения

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

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

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

Последние мысли

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

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

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

Спасибо, что прочитали эту статью. Я надеюсь, что были сделаны некоторые наводящие на размышления предложения, и что вы уйдете с некоторыми новыми идеями. Если у вас есть какие-либо отзывы, пожалуйста, запишите их в разделе комментариев ниже. Я всегда стараюсь учиться и совершенствоваться, и было бы здорово услышать другие мнения и даже критические замечания по этому поводу. Мы все здесь, чтобы учиться!

Ресурсы