Как управлять проектом, когда он заморожен / задержан на неопределенное время
Прямо сейчас я крайне разочарован, потому что я занимался разработкой какого-то крутого механизма для оптимизации системы вычислений путем сокращения количества вычислений с примерно полумиллиона до нескольких тысяч. Потребовалось много времени, чтобы изучить и проанализировать данные, записать что-то, сделать несколько тестов и вообще просто выполнить свою работу. Затем у нас была встреча по проекту. Я объяснил, что я хотел сделать, сколько времени это займет и сколько он может улучшить проект и даже сделать возможным создание новых функций. Тогда было решено, что это было слишком много времени, чтобы сделать все это до следующего срока. (Крайний срок, который должен был бы быть продлен, если бы мне разрешили продолжить.) Быстрый мозговой штурм дал понять, что вместо этого можно использовать простой обходной путь, который задержит оптимизацию еще на несколько месяцев.
Ну, круто!
Хорошо... Я только что написал разочарование. Теперь вопрос... У меня теперь есть весь этот дизайн в моей голове. Многое из этого - просто схемы и листы бумаги с рукописным текстом на нем, некоторые распечатки и даже несколько вопросов здесь, в SO. Эти идеи будут заморожены на некоторое время, но мне нужно будет вспомнить их в будущем. Я могу получить день, может, два, чтобы почистить заметки и начать документировать вещи.
Поэтому мне нужен совет о том, как лучше запомнить мой дизайн, например, через 4 месяца. Или, может быть, даже через год... Что было бы самым важным записать? Или документ? (Учитывая, что у меня мало времени...) Есть предложения?
Зачем? Иначе через четыре месяца я снова разочаруюсь. :-)
5 ответов
Это зависит от того, что работает для вас - и как вы любите учиться. Мне нравится использовать диаграммы, поэтому в ситуации, когда я разработал классный алгоритм (хотя и ничего сложного!), Я делаю следующее:
1) Нарисуйте алгоритм на бумаге или напишите его как угодно.
2) Добавьте аннотации к нему, чтобы он имел для вас полный смысл.
3) Опишите алгоритм кому-то еще только из того, что вы нарисовали. Это мешает вам заполнить пробелы из ваших собственных знаний алгоритма.
4) Если в вашем описании есть пробелы, добавляйте дополнительные подробности по мере продвижения, чтобы документ стал полной записью вашего описания.
5) Уберите рисунок на неделю и посмотрите, имеет ли он смысл. На этом этапе он все еще должен быть достаточно знаком, чтобы добавить недостающие детали.
Будет ли это достаточно ясно через год - или вы даже захотите его использовать - еще неизвестно.
Надеюсь, это поможет!
По моему опыту, старые проекты всегда кажутся несвежими, когда от них отряхивают В ближайшие месяцы существующий код изменится, требования изменятся, и вы станете программистом. Возможно, вам следует написать краткое объяснение и предположить, что вам все равно придется полностью переработать его в будущем.
Не расстраивайтесь из-за конкретных проектов, сосредоточьтесь на совершенствовании в качестве разработчика. И нести этот опыт с собой.
С точки зрения разочарования - обычно старайтесь рассматривать проект как путешествие, а не пункт назначения.
Если вы обратили внимание, вы получите много полезного от проекта на сегодняшний день - то, что вы узнали о технологиях и бизнесе, создали модули кода, которые вы можете использовать повторно, вы построите отношения с членами команды. или пользователи, допустившие ошибки, которые вы не будете делать снова и так далее. Это может помочь вам лично написать список того, что вы знаете сейчас, чего не знали в начале проекта.
В конечном счете, компания, возможно, не реализовала проект, но большая часть выгоды, которую вы получаете как личность и разработчик, все еще здесь. Действительно, часто вы узнаете больше о проектах, которые идут не так, и о компаниях, которые не так хороши, как когда дела идут как в мечте.
Как и в случае с остальной жизнью, чем больше вы можете получать удовольствия от повседневных дел, и чем меньше вы сосредотачиваетесь только на основных достижениях, тем счастливее вы будете.
Я не говорю, что реализация проектов - это нехорошо - это, очевидно, то, почему мы кодируем, - но это не полностью в нашем контроле, поэтому вам нужно быть реалистичным и сбалансированным, насколько вы позволяете этому влиять на вас.
(Обязательная ссылка на что-то, что написал Джоэл или Джефф: http://www.codinghorror.com/blog/archives/001297.html)
Если вы нашли Решение один раз, велика вероятность, что вы найдете решение даже через 4 месяца для той же проблемы. То, что вы ДОЛЖНЫ не пропустить, является актуальной проблемой.
Вы должны записать все проблемы оптимизации, которые являются источниками проблемы или фактическими проблемами. Вы должны аккуратно вести записи об этих проблемных вопросах.
Теперь, в следующий раз [скажем, через 4 месяца], когда вы захотите вернуться к этому снова. Вам просто нужно прочитать проблемные вопросы из ваших заметок, и ваш мозг начнет работать в прямом направлении, как это было раньше.
Чтобы сделать его еще лучше, вы можете попробовать просмотреть примечания к проблеме раз в месяц или два. Это научит ваш мозг к решению, так как вы всегда будете получать решение, как и в первый раз.
Кроме того, если вы можете решить проблему или проблему, которая действительно мотивировала вас достаточно, чтобы бороться за решение, это было бы здорово.
Подробный документ с требованиями, который описывает все входы и выходы, вероятно, является одним из лучших способов начать работу. Если это очень уникальный дизайн кода, метакод может быть хорошим шагом. то есть.
[Meta Object]
[Return String(string param1, string param2)]
Return param1 + " " + param2
[Return Integer(integer param1, integer param2, integer param3)]
Return (param1 + param3) / param2
[End Meta Object]
Сделайте так, чтобы это выглядело как-то похоже на ваш язык без тестирования или чего-то еще, просто перенесите теоретический журнал на бумагу (блокнот) таким образом, чтобы у вас была пружинная доска, когда / если вам когда-нибудь придется вернуться к ней... затем задокументируйте дневное освещение из этого.