Программирование против планирования [закрыто]

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

Можно ли все еще быть хорошим программистом, не будучи планировщиком высокого уровня?

Будучи старшим программистом, можно ли рассчитывать на планирование всего продукта и выбор даты завершения?

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

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

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

Прочитайте Agile Manifesto и посмотрите на Scrum . Используйте метод итеративной разработки и разработки динамических систем для руководства проектом.

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

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

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

Можно ли быть хорошим программистом, а не планировщиком высокого уровня?

Какое-то время да. Возможно ли это сделать долго? Нет.

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

Конечно, вы можете быть хорошим программистом с точки зрения программиста. С точки зрения менеджмента это совсем другой вопрос. По моему опыту, участие в процессе планирования - лучший способ 1) получить более интересные задания по программированию и 2) выполнять их так, как вы хотите.

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

Если вы довольны таким положением дел, вам больше под силу. Большинство людей становятся менее довольны тем, что больше опыта они получают.

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

Можно ли быть хорошим программистом, а не планировщиком высокого уровня?

Краткий ответ: Да, это возможно.

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

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

Да и Нет, ваши ответы.

С одной стороны, вас подталкивают к управлению проектами. ИМО, у всех хороших программистов есть некоторая способность к управлению проектами, но это разные навыки. Способность планировать на долгосрочную перспективу улучшает вашу способность общаться с фактическим управлением проектом. Так что «нет», вы не можете быть хорошим программистом без способности планировать на длительный срок.

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

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

Планирование и Bungie-Boss

У Дилберта много поводов про босса. Наши проблемы и ожидания в отношении планирования могут быть как причиной, так и следствием лидерства. Мой опыт работы в компании из списка Fortune 100 заключался в том, что через год ушли все, кто начинал год в качестве руководителя проекта. Возможно, это было связано с проблемой планирования. Не уверен, что ваш прежний лидер оставил по этой причине, но когда ваша роль требует от вас, вы должны составить план с обязательством, если он не выполняется, часто результатом является выход из-за предельного срока.

Организационный контекст планирования

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

Планирование является важным инструментом. Не пренебрегай этим. Не поймите меня неправильно.

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

Простой пример планирования - не должно быть о программном обеспечении ...

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

Стать лучшим планировщиком

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

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

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

SLIM - это метод, изобретенный Путнэмом после работы в GE и других компаниях над проектами DoD в 1970-х годах. SLIM является влиятельным, и его компания QSM предлагает сертификацию, которая, кажется, вытекает из созданного ими инструмента. В зависимости от того, принял ли ваша компания их инструмент, он может не иметь никакой ценности или иметь высокую стоимость.

Стив Макконнелл (автор Code Complete) также написал книгу об оценке программного обеспечения, а его компания Construx преподает два класса для кредитов PDU , которые аккредитованы в Институте управления проектами. У меня есть его книга, и если бы я хотел узнать об этой теме в классе, я бы, вероятно, выбрал Construx. Они также проходят обучение Scrum и проводят различные оценки Scrum, аккредитованные через Scrum.org.

Другим источником, который мог бы обеспечить отличную академическую подготовку по оценке программных проектов, была бы группа Барри Бёма в USC , основанная на их обширной работе над конструктивным моделированием затрат COCOMO и COSYSMO, которая использовалась в НАСА и других крупных подрядчиках для оценки очень крупных проектов. Я не уверен, что я действительно верю в COCOMO, но мне нравится эмпирическая работа, которую они проделали, чтобы соотнести влияние масштабов и стоимостных факторов на продолжительность графика.

Я также нашел главу из учебника, изданного О'Рейли, в котором кратко обсуждаются основные методы оценки программного обеспечения, включая Уоттса Хамфриза ПРОБЕ и игру по планированию Кента Бека. PROBE включает в себя понятие, что инженеры отслеживают метрики по собственной продуктивности, а затем применяют их для своей части назначения в новых проектах. Planning Game очень тесно сотрудничает между разработчиками и другими заинтересованными сторонами.