Управление программным обеспечением
Почему некоторые старшие разработчики не готовы возглавить
Управление командой требует гораздо большего, чем просто разработка программного обеспечения
После того, как мы получили звание старшего разработчика программного обеспечения, естественно, что наше следующее стремление - стать ведущим разработчиком. Ведущий разработчик - это позиция, в которой человек все еще технически очень вовлечен, но больше не выполняет все кодирование самостоятельно. Вместо этого этот человек работает с другими разработчиками над проектом.
Это может показаться простым, просто сделайте еще один проект. Однако есть нюансы, которые нужно знать, чтобы успешно вести проект. Неспособность их решить может привести к ненужной нагрузке или помешать успеху проекта. Ниже приведены несколько моментов, о которых следует помнить.
Отношение «Пожалуйста, дайте мне все требования».
Менеджер по продукту: «Нам нужно создать функцию сохраненных пользовательских заметок».
Старший разработчик: «Хм… где вы хотите ее сохранить? На устройстве или на сервере? Какой формат вы хотите, чтобы мы сохранили? А как насчет этого ... этого ... Нам понадобится все это, прежде чем мы сможем что-нибудь придумать ».
Как разработчики, мы любим, когда к нам предъявляют особые требования. Лучшими являются точные требования, в которых нет двусмысленности. Без них невозможно продолжить работу над проектом. Это типичный менталитет некоторых разработчиков.
Для приведенного выше примера «сохранить примечание» с технической точки зрения приведенное выше требование действительно расплывчато. Есть много вариантов и соображений, которые следует учитывать.
Разработчик задал правильные вопросы. Однако с точки зрения продукта это относительно ясно (при условии, что дизайн указан). Продакт-менеджер не сможет проконсультировать по всем техническим аспектам.
В качестве лидера нам придется принять такое «расплывчатое» требование, проработать детали и прояснить их с точки зрения разработки, чтобы разработчики могли работать над ними.
Нам не будут предъявлять «все требования». Вместо этого мы несем ответственность за определение этих «требований», чтобы заполнить пробел между тем, что просит менеджер по продукту, и тем, что разработчики могут предпринять для начала работы.
Тем не менее, можно задавать вопросы для разъяснения с точки зрения продукта или компромисса между техническими и бизнес-аспектами. Сказав это, как руководитель, нужно быть готовым давать рекомендации и предлагать варианты, когда дело доходит до технических требований, вместо того, чтобы ждать, пока ему сообщат подробности.
«Это просто, все можно легко сделать, не думая широко».
Менеджер по продукту: «Нам нужно создать функцию сохраненных пользовательских заметок».
Старший разработчик: «Это кусок пирога, легко. Ему просто нужно ввести данные пользователя и сохранить его в файл ».
Причина, по которой человека назначают старшим разработчиком, заключается в том, что он обладает набором сильных технических компетенций - с отношением «все готово». Это большой плюс старшего разработчика.
Отношение «все можно сделать», если с ним не работать должным образом и без каких-либо ограничений, может привести к чрезмерной самоуверенности, что может привести к чрезмерному упрощению данного проекта. Такое отношение может заставить человека не принять меры предосторожности или не заметить, что действительно требуется, что находится на месте и какие непредвиденные осложнения могут быть причиной запроса.
Как разработчик, всякий раз, когда нам поручают задачу от нашего ведущего разработчика, более вероятно, что задача уже правильно определена, хорошо продумана и решена. Следовательно, мы можем принять задачу такой, какая она есть, поскольку ее выполнимость предварительно проверена.
Однако в качестве ведущего нам дают относительно грубое требование. Технический аспект этого еще предстоит решить. Даже если задача может показаться простой, вероятно, есть много крайних случаев, которые следует рассмотреть, варианты, которые необходимо оценить, и то, как задача должна использоваться или связываться с существующими системами. Это требует либо опыта, либо сознательного мыслительного процесса, чтобы подготовиться заранее, прежде чем приступить к делу.
Пример функции сохранения заметок может быть простой задачей для индивидуального разработчика, если он владеет всей небольшой частью программного обеспечения. Но в более крупной организации любые представленные функции с большей вероятностью будут связаны с другими системами, которые следует учитывать перед разработкой, например, как серверная служба должна обрабатывать их, как мы управляем синхронизацией и т. Д. Следовательно, это может не быть таким «легким занятием», как кажется.
Сказав это, это не значит, что ни один проект не может быть простым. Это просто означает, что значение слова «простой» необходимо уточнять, исходя из опыта работы с промышленными требованиями и организационного контекста того, что возможно.
«Я знаю, что ему нужно, только после того, как поработаю над этим; Нет возможности разделить мою задачу ».
Менеджер проекта: «Могу я попросить кого-нибудь помочь вам с работой?»
Старший разработчик: «Мне лучше работать самому, так как есть нет возможности понять, что нужно, пока я над этим не поработаю. Не думаю, что кто-нибудь может мне помочь ».
Некоторые разработчики очень хорошо справляются с получением карты. Они могут поэкспериментировать, а затем красиво разработать вещь, оптимизировать ее и провести хорошие тесты. Изначально им дается простое задание, а значит, на это уходит 1-2 дня. Когда передается более крупная задача, это по-прежнему будет одна карта, но это займет больше времени - от 3 до 4 дней.
Не потому, что они не любят разбивать задачи на более мелкие части. Просто для этого требуется опыт и время, потраченное на планирование. Без опыта и готовности тратить это дополнительное время никто не сможет правильно или вообще разделить задачи. Даже если они разделены, небольшие задачи часто пересекаются друг с другом без четкого разделения того, как они связаны друг с другом. Определение выполненного для каждой задачи нечеткое.
Тенденция разработчиков состоит в том, что когда возникает требование, нужно сразу перейти к кодированию и посмотреть, как оно продвигается. Естественно, как разработчик, мы считаем, что планирование - пустая трата времени. Без кодирования кажется, что ничего не сделано. Мы нервничаем. Все это время наши поставки - это код и продукты. Следовательно, мы хотели бы начать кодирование в ближайшее время и минимизировать накладные расходы.
Привычка «писать код немедленно» не работает, когда дело доходит до более крупной задачи. Это ограничивает проект, поэтому над ним может работать только один человек, и это не идеальная «практика кодирования». В идеале, даже для небольших задач, продуманный процесс того, как его можно разбить и правильно структурировать, окупится позже.
Способность разбивать проекты на соответствующие выполнимые более мелкие задачи требует навыков и экспериментов с осторожными мыслями и соображениями. Это не то, что можно включить и сделать сразу, когда вы станете лидером.
Следовательно, следует начать с изучения того, как разбить задачу среднего размера на несколько более мелких задач - и постепенно набираться опыта при работе над более крупными задачами. Со временем это станет более естественным, и его можно будет легко визуализировать, даже не требуя слишком большого умственного процесса.
«Мне нужно выяснить все детали, прежде чем я смогу четко спланировать проект».
Менеджер проекта: «Можем ли мы разделить эту часть работы, чтобы получить оценку?»
Старший разработчик: «Дайте мне немного времени, чтобы написать код. все подробности. Это займет все, что нужно ».
Хорошо, нам нужно спланировать проект, разбив его на небольшие задачи. Важно, чтобы эти задачи были хорошо связаны и между ними были четкие перегородки. Для этого некоторые разработчики планируют все мелкие детали, например, какие классы, функции, переменные-члены и т. Д.
Каждая задача была так хорошо отшлифована и содержала точные шаги того, что нужно сделать, чтобы получить карту. Иногда в нем даже есть псевдокод того, как это можно сделать. Сама карточка задачи похожа на готовый код, за исключением того, что она написана на английском языке вместо кода.
Хотя это звучит действительно здорово, это непрактично. Чтобы подготовить такие подробные карточки задач, на них тратится слишком много времени. Используемое время иногда может быть равно времени, необходимому для реальной работы. Сейчас узкое место находится на стадии планирования, так как оно решается одним человеком, который выполняет такое подробное планирование.
Как ведущий разработчик, мы должны научиться планировать только высокоуровневые детали, но опускать низкоуровневые детали. Это важно как с точки зрения эффективности, так и гибкости. В каждой карточке нам просто нужно достаточно информации о «что делать» вместо «как делать». Мы сэкономим время, а также дадим возможность «практическим действиям» развиваться с большим количеством времени на планирование.
Ведущий разработчик может, возможно, закодировать начальную высокоуровневую структуру и заглушки в качестве подготовки для последующих карточек, чтобы добавить их детали позже. Такая высокоуровневая структура, однажды созданная, позволяет разработчикам выполнять последующую разработку параллельно.
Таким образом, ведущему разработчику не нужно вдаваться в подробности, прежде чем можно будет начать разработку. Каждый приступает к работе раньше.
Принуждение «Это должно быть сделано только одним-единственным способом».
Разработчик: «Могу ли я изучить новый способ работы?»
Старший разработчик: «Я занимаюсь этим годами! Почему бы тебе просто не поверить мне и не следовать тому, что я тебе только что сказал?
Как старшие разработчики, мы обладаем опытом и имеем фиксированный набор идей о том, как все должно быть сделано. Иногда у нас действительно есть философский взгляд на определенные аспекты развития, в котором нет правильного или неправильного. Это прекрасно.
Однако иногда, если мы не будем осторожны, мы можем впасть в установку на данность, что «один и только один способ делать что-то» всегда верен. Это определенно не всегда плохо, если мы технически наиболее компетентный человек в нашей группе, и продолжаем им оставаться, даже если у нас меньше времени на программирование и обучение.
Чаще всего мы, люди, несовершенны, и мы лучше работаем в команде с коллективным набором знаний и опыта. Таким образом, для нас очень важно различать то, что мы считаем лучшим, и то, что команда считает лучшим.
Иногда то, что команда предпочитает, не имеет для нас смысла на начальном этапе, но как ведущий разработчик должен иметь возможность рационализировать и гибко подходить к решению команды, если только у нас нет кристально четкого представления, которое абсолютно неверно.
Во-вторых, в качестве лидера мы определяем задачи высокого уровня. Когда дело доходит до низкоуровневых задач, возложенных на разработчика, очень важно предоставить разработчику пространство для более гибкой работы над тем, как должны быть решены задачи, вместо того, чтобы мы все давали по мандату.
Нам нужно выяснить, что нужно выяснить, чтобы разработчики имели возможность выяснить элементы нижнего уровня. В лучшем случае мы можем предоставить рекомендации и советы, которые достаточны для того, чтобы не отклоняться от норм команды, но при этом оставлять разработчику достаточно места для исследований и инноваций.
В этом есть много преимуществ. Во-первых, он более масштабируемый (т.е. ведущему разработчику не нужно решать все детали). Во-вторых, общие знания и навыки команды также будут расширяться. В-третьих, разработчик чувствует себя более уполномоченным и вносит больший вклад.
Умение работать в команде имеет решающее значение для ведущего разработчика. Важно помнить, что, хотя мы играем ведущую роль, мы не находимся в роли диктатора.
«Документация - это всего лишь эссе моего мыслительного процесса. Никаких диаграмм, никаких таблиц, только слова »вялость.
Разработчик: «Можно ли нарисовать диаграмму, чтобы лучше проиллюстрировать процесс?»
Старший разработчик: «Все написано в документе. Просто прочтите… и прочтите еще несколько раз, если не можете понять ».
Многие разработчики не любят писать документацию. Кодировать веселее, чем писать документы. Но все поняли и согласились работать над большим проектом. Нам нужно задокументировать и сообщить, что необходимо. Следовательно, это неизбежное зло.
Чтобы написать, некоторые просто напишут шаги один, два, три и т. Д. Без контекста. Никаких дополнительных подробностей в диаграмме о том, как работает сложный поток, только длинный абзац - как эссе - излагающий, как это делается.
Рисование диаграмм и таблиц является громоздким делом, поскольку для большинства инструментов требуется использование мыши. Разработчики просто любят печатать и не отрывать пальцы от клавиатуры. Следовательно, писать и печатать «эссе», хотя и не весело, но все же терпимо. Работа заключается в том, чтобы просто подготовить документ. «По крайней мере, я сделал это».
Однако, как ведущий разработчик, документация - это один из наших продуктов. Он будет использоваться, чтобы донести суть проекта до разработчиков. Хорошая документация обычно сопровождается диаграммами и таблицами, особенно к тем проектам, которые требуют работы над системами и потоками. Общепризнано, что люди лучше визуализируют технические знания с помощью диаграмм и таблиц.
Опять же, это область, в которой нужна практика, желание четко сообщить, о чем проект, и как он будет разбит на части и над чем будет работать. Если это сделано правильно, 50% того, что нужно сделать ведущему разработчику, будет выполнено. В будущем, когда разработчики будут работать над задачами, это будет справочный материал. Следовательно, усилия, приложенные к нему, окупятся очень хорошо.
Помимо общения, хорошо продуманная документация - это хорошее умственное упражнение для выявления упущенных областей, угловых ситуаций и вариантов, имеющихся в проекте. По моему опыту, когда я рисую диаграммы и таблицы, я часто замечаю недостающие части в моих мыслях и задаю дополнительные вопросы, на которые мне нужно ответить.
Иногда, как автор документов, я забываю содержание, и документ помогает мне напоминать. Диаграмма помогает мне быстро резюмировать и объяснять области без необходимости сканировать и читать абзацы слов. Польза огромна.
Постарайтесь разместить несколько диаграмм, таблиц и всего остального, что сделает ваши процессы легко доступными для всех остальных. Просто написать «эссе» технической документации не так удобно.
TL;DR
Наша основная роль как разработчика и старшего разработчика - работать над проектом, кодировать и поставлять программный продукт. Кодирование - это основа того, что мы делаем.
Чтобы перейти на следующий уровень - ведущий разработчик, где мы все еще должны быть технически значимыми - наша основная роль больше не производить продукты путем кодирования, а технически готовить, как проект может быть успешно запущен и эффективно продвигаться.
Поэтому, прежде чем старший разработчик сможет перейти на позицию ведущего разработчика, важно, чтобы он начал изучать аспекты, упомянутые выше, и попытаться изменить некоторые типичные атрибуты разработчика, «ограничивающие карьеру».
Это правда, что ведущий разработчик не сможет столько кодировать. Вместо этого вы напишете больше документов и проведете больше встреч. Удовлетворение больше не приходит от кодирования и хорошей компиляции, а от того, как разработчики без проблем работают над проектом.
В конце концов, вы по-прежнему видите поставленный продукт, зная, что это не ваше единственное усилие, а действительно командное усилие. Это уже не маленький проект, а более крупный проект, с которым нельзя справиться в одиночку.
Мой босс однажды сказал мне: «Если вы успешно отправите продукт, написав его самостоятельно, вы все равно проиграете». Работа с командой - ключ к успеху.
