Обычно вы пишете программы для других людей. Часто вы вспоминаете о том, что хорошо бы получить от них требования [2]. Но как часто вы спрашиваете их, а насколько хорошими они хотят видеть эти программы? Иногда выбирать не из чего. Если вы работаете над передовыми технологиями, космическим челноком, или низкоуровневой библиотекой, которая будет широко распространяться, то требования будут более строгими, а варианты – ограниченными. Но если вы работаете над новым продуктом, то у вас будут ограничения другого рода. Маркетологам придется сдерживать обещания, вероятные конечные пользователи могут строить планы, основанные на дате поставки программы, а ваша фирма, конечно, будет ограничена в денежных средствах. Профессионалы не могут игнорировать требования пользователей – просто добавить к программе новые средства или «отшлифовать» еще раз тексты программ. Мы не призываем к паническим настроениям: одинаково непрофессионально обещать невероятные сроки и срезать основные технические углы чтобы уложиться вовремя.
Сфера действия и качество создаваемой вами системы должны указываться в части системных требований.
Подсказка 7: Сделайте качество одним из пунктов требований
Часто вы будете оказываться в ситуациях, когда необходимо идти на компромисс. Удивительно, но многие пользователи предпочтут использовать программы с некоторыми недоработками, но сегодня, чем год ожидать выпуска мультимедийной версии. Многие IT-департаменты, имеющие ограничения по бюджету, могли бы согласиться с этим утверждением. Хорошие программы (но сегодня) зачастую являются более предпочтительными по сравнению с отличными программами (но завтра). Если вы заранее дадите другим пользователям поиграться с вашей программой, то часто их отзывы будут способствовать выработке лучшего конечного решения (см. Стрельба трассирующими).
Знайте меру
В ряде случаев программирование подобно живописи. Вы начинаете с чистого холста и определенных базовых исходных материалов. Используете сочетание науки, искусства и ремесла, чтобы определить, что же делать с ними. Набрасываете общую форму, выписываете основу, затем работаете над деталями. Постоянно отступаете назад, чтобы критически взглянуть на то, что же вы сделали. Иногда отбрасываете холст и начинаете снова.
Но художники скажут вам, что вся тяжелая работа идет насмарку, если вы не знаете, в какой момент нужно остановиться. Если вы добавляете слой за слоем, деталь за деталью, живопись может потеряться в краске.
Не стоит портить очень хорошую программу путем приукрашивания и излишней шлифовки. Двигайтесь вперед и дайте вашей программе отстаивать свои права в течение какого-то времени. Она может быть несовершенной. Не беспокойтесь, возможно, она никогда не станет совершенной. (В главе 6 мы обсудим философию разработки программ в несовершенном мире.)
Другие разделы, относящиеся к данной теме:
• Стрельба трассирующими
• Западня требований
• Команды прагматиков
• Большие надежды
Вопросы для обсуждения
• Обратите внимание на производителей инструментальных программных средств и операционных систем, которыми вы пользуетесь. Можете ли вы найти свидетельство тому, что эти компании не испытывают неудобства, поставляя программное обеспечение, хотя им известно, что оно несовершенно? Как пользователь, вы скорее: (1) подождете, пока они устранят все ошибки, (2) выберете усложненную версию программы и примете отдельные ошибки или (3) выберете упрощенную версию программы, но с меньшим числом дефектов?
• Рассмотрите эффект разбиения на модули при поставке программного обеспечения. Больше или меньше времени потребуется для доведения монолитного программного блока до требуемого уровня качества по сравнению системой, спроектированной по модульному принципу? Можете ли вы привести коммерческие примеры?
Портфель знаний
Инвестиции в знания окупаются лучше всего.
Бенджамин Франклин
Ах, старина Франклин! Никогда не лез в карман за многозначительным наставлением. Если бы мы рано ложились и рано вставали, мы стали бы великими программистами, не так ли? Ранняя птичка никогда не остается без червячка, но что при этом происходит с червячком?
Хотя в данном случае Бенджамин действительно попал в точку. Знание и опыт являются самыми важными профессиональными активами.
К сожалению, знания и опыт представляют собой истекающие активы [3]. Ваше знание устаревает по мере того, как разрабатываются новые методики, языки, технологии и операционные среды. Изменение расстановки сил на рынке может сделать ваш опыт устаревшим или полностью неприменимым. Принимая во внимание скорость, с которой промчались годы Интернета, это может произойти довольно быстро.
По мере того как величина ваших знаний уменьшается, то же самое происходит с ценностью вас для фирмы-работодателя или заказчика. Мы хотели бы предотвратить возникновение подобной ситуации.
Ваш портфель знаний
Портфелями знаний мы предпочитаем называть все факты, известные программистам об информатике, области приложений, в которых они работают, и накопленный ими опыт. Управление портфелем знаний очень похоже на управление финансовым портфелем:
1. Серьезные инвесторы инвестируют регулярно – это как привычка.
2. Диверсификация – это залог успеха в течение длительного времени.
3. У проворных инвесторов портфель всегда сбалансирован – в нем имеются и консервативные, и высокорисковые, высокодоходные инвестиции.
4. Инвесторы стараются покупать ценные бумаги подешевле и продавать их подороже, обеспечивая тем самым максимальный возврат.
5. Портфели нуждаются в периодическом пересмотре и повторной балансировке.
Управляйте вашим портфелем знаний, используя те же самые принципы, и ваша карьера будет успешной.
