Около двух месяцев назад я устроился на новую работу в качестве старшего инженера-программиста в компании, производящей программные продукты. После нескольких заданий, которые, как мне показалось, в разумных пределах соответствовали моему уровню предметной области, мне было поручено задание, затрагивающее изменение архитектурных основ нашего приложения и в то же время довольно недетерминированное по своей природе и не имеющее конца. Другими словами, пройдет много времени, прежде чем я смогу завершить это задание. Под «недетерминированным» я подразумеваю такие вопросы, как «Какого цвета рубашка мне надеть на вечеринку?» против «Должен ли я носить более или менее теплую одежду в походе, учитывая прогноз погоды?», Что было бы более детерминированным.
На данном этапе моего пребывания в компании я в первую очередь заинтересован в создании легко поддающихся количественной оценке показателей производительности, и под этим я подразумеваю количество закрытых тикетов Jira и количество ревизий файлов, связанных с моим именем в системе контроля версий. Поэтому я хочу иметь много небольших заданий, которые я могу определить и завершить, и которые носят более детерминированный характер, предлагая четкое представление о направлении. Я хочу, чтобы руководство, которому я не подчиняюсь напрямую, имело легко потребляемый список закрытий, связанных с моим именем, в отличие от одного большого проекта, который все еще «незавершен», и конца ему не видно.
Сегодня я разговаривал с боссом и объяснил ему все это. Я рассматривал это с точки зрения своего когнитивного стиля и типа личности и пытался убедить его в том, что мне можно ставить более разумные задачи тактического характера и что таким образом я могу быть более продуктивным. Я действительно не хочу длинного задания. Я предложил временное исправление, которое не является долгосрочным решением, надеясь добавить в проект веху, которую можно приостановить, но они хотят капитального ремонта архитектуры. Он сказал, что у него будет больше мелких заданий для меня, но ему придется каждую неделю посвящать какое-то время этому адскому архитектурному изменению.
Есть ли что-то еще, что я мог бы сделать, чтобы убедить руководство, что я могу быть гораздо более продуктивным с узкими задачами, а не с задачами высокого уровня, не нанося ущерба их восприятию меня как разработчика? Я все о ЗАКРЫТИИ , и меня стимулирует наличие множества небольших поддающихся количественному измерению закрытий под моим животом, чем работа над длинными проектами, которые требуют большого анализа и планирования. Я очень нервничаю, когда долго не проверяю что-то, думая, что из-за отсутствия ощутимых достижений меня уволят. Это и я действительно больше исполнитель, тактичный парень, который предпочитает мгновенное удовлетворение, чем долгосрочный планировщик/дизайнер/аналитик. Я хочу быть программистом-реализатором, который пишет код, а не занимается архитектурным проектированием.
Хотя я не возражаю против того, чтобы вы стремились к определенному рабочему стилю или стилю назначения, я бы возражал против того, чтобы кого-то называли (и платили) старшим, если он отказывался браться за бессрочные проекты с высокими ставками неопределенной продолжительности. Так делают пенсионеры. Ведь если не ты, то кто?
Если бы вы далее пояснили мне, что ваша причина заключалась в том, что вы хотели установить высокие показатели производительности, особенно с руководством в других отделах, я был бы крайне разгневан , хотя я мог бы не раскрывать это вам.
Будьте благодарны, что вам доверили что-то большое. Составьте план и имейте возможность отслеживать свой прогресс в соответствии с планом. (Этот план может включать в себя несколько завершающих пунктов, таких как «У меня есть регрессионные тесты, которые мне нужны в качестве подстраховки» и «Я заменил все старые X на новые Y», чтобы они соответствовали вашим внутренним потребностям.) Регулярно отчитывайтесь. по мере продвижения по плану. Делайте свою работу хорошо, и вы добьетесь высоких результатов. Вместо этого попросите, чтобы вас кормили с ложечки небольшой легкой работой, которую все умеют делать, а вы не будете.
В конце концов, вас наняла компания, ожидая, что вы сможете выполнять такую работу. Все, что продемонстрирует неспособность выполнить эту работу, будет «наносить ущерб их восприятию меня» .
Вы были наняты компанией для выполнения конкретной работы. Ваши навыки и описание работы обсуждались в процессе собеседования, и в результате вы решили работать в этой компании. Сказать через 2 месяца после этого процесса, что вы на самом деле хотите выполнять совершенно другую работу, чем та, для которой вас наняли, будет «повреждать их восприятие меня» , потому что это не соответствует ожиданиям, которые они имели, когда соглашались нанять вас.
Посмотрите на свои приоритеты. Сейчас похоже, что они у вас в таком порядке:
На данном этапе моего пребывания в компании я в первую очередь заинтересован в создании легко поддающихся количественной оценке показателей производительности.
Компании имеют ограниченные ресурсы для выполнения задач различной важности для их успеха. С полным пониманием того, какие задачи требуются, и какие задачи наиболее важны для них как для компании, они поставили вас (старшего разработчика) эту задачу над другими. Они считают это важным, и это делает его очень легко поддающимся количественному измерению показателем производительности:
Как только вы поймете, что вас наняли для выполнения работы, и эта работа должна быть завершена, вы сможете найти альтернативу, которая позволит достичь целей компании, уважая при этом « мой когнитивный стиль и тип личности» . Например, вы можете попросить поддержки у разработчика, действительно заинтересованного в общих вещах, и предложить работать в команде, чтобы убедиться, что его задачи будут выполнены, а общие вещи будут завершены. Вы можете передать ему всю общую картину и взять на себя часть его рабочей нагрузки, чтобы получать ваши проверки.
Это не означает, что компания будет высокого мнения о вас (в конце концов, вы, по сути, закладываете свою работу тому, кто получает меньше, что может дать им намек на вашу относительную значимость для компании), но это, безусловно, будет более эффективным. чем говорить: «Я не хочу делать эту работу, вместо этого дайте мне совершенно другую работу небольшими порциями».
Я думаю, Кейт права, что у тебя должен быть план. Однако на самом деле я переписал существующий проект, так что вам может быть полезно услышать, как я это сделал.
Первое, что я сделал, это записал все задачи, которые я мог придумать и которые нужно было выполнить, прежде чем у нас была бы готовая к использованию версия. Затем я записал оценки того, сколько времени займет каждая из них, и занес их в электронную таблицу. В конце концов я также ввел их в Asana, чтобы любой член команды мог видеть, где я находился в проекте, но я всегда обращался к электронной таблице для оценки времени, потому что, очевидно, в Excel проще суммировать числа.
Получив электронную таблицу, я смог рассылать отчеты о проделанной работе и давать оценки того, когда будут завершены различные части проекта. Я работал как собака, чтобы удостовериться, что я достиг своих оценок (не обязательно с точностью до часа, но, конечно, если бы я сказал, что сделаю то и другое за 8 рабочих дней, я бы удостоверился, что уложусь в это, даже если бы мне пришлось работать 10-12). часовые сутки). Это дало мне больше внутренней мотивации, чем я получил от своего начальника, так как поначалу дедлайна не было, и мы все еще могли использовать старую платформу.
И у меня все еще есть электронные таблицы, которые я мог бы использовать для обновления своего резюме, но спустя год преимущества платформы интереснее, чем список того, что я сделал для этого.
Во время записи всего этого вы, вероятно, обнаружите, что на самом деле у вас нет четкого представления обо всем, что нужно сделать. Вероятно, основная причина, по которой никто не хочет работать над этим, заключается в том, что их чутье подсказывает им, что они не совсем знают, что делать. Будьте тем парнем, который действительно может решить эту проблему, выяснив эти проблемы и выяснив требования.
Одна из задач, которая явно должна быть в вашем списке дел (но явно не входит в нее), — поставить проект под контроль версий. Нет никаких причин, по которым вы не можете отмечать каждую часть, когда вы ее редактируете, по крайней мере, в ответвлении.
Кстати, вполне возможно, что вы занесли себя в список «пожарных, когда это практично», действуя как примадонна. Я не думаю, что у меня когда-либо был босс, который даже подумал бы посмотреть на проверки, чтобы увидеть, кого уволить - так же, как когда-то в частном порядке я чувствовал, что это было бы хорошей идеей ;).
амфибия
Эндрю Бартель
амфибия
IDRinkandIKnowThings