Студопедия
Случайная страница | ТОМ-1 | ТОМ-2 | ТОМ-3
АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатика
ИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханика
ОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторика
СоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансы
ХимияЧерчениеЭкологияЭкономикаЭлектроника

Не выполняйте задания, а распределяйте их

Читайте также:
  1. БИЛЕТЫ, ТЕСТОВЫЕ ЗАДАНИЯ, СИТУАЦИОННЫЕ ЗАДАЧИ
  2. Вторая часть. Задания, оцениваемые в 3 балла.
  3. Выполняйте самую трудную задачу в первую очередь
  4. Но, с точки зрения оформления задания, метод подведения функции под знак дифференциала гораздо короче.
  5. Степень трудности должна определяться не только сложностью задания, но и индивидуальными возможностями учащихся.
  6. Третья часть. Задания, оцениваемые в 5 баллов.

 

Классическая управленческая ловушка для начальника, вышедшего из программистов, касается распределения заданий. Вы понимаете, каким образом реализовать определенное решение, а обучение членов команды, которые вовсе не обязательно видят это решение, требует времени. Здесь применима старая китайская поговорка: «Дайте человеку рыбу, и он будет сыт один день; научите его ловить рыбу, и он будет сыт всю жизнь». Если бы все стали столь же сообразительны, как вы, было бы вам проще работать? Возможно. Потратьте время на обучение сейчас, и вы сэкономите его потом, поскольку ваши сотрудники научатся решать проблемы без вашей помощи. Тогда вы сможете эффективно распределять задания, а не давать объяснения.

 

Документируйте то, что вы делаете или планируете делать

 

Трудным заданием для тех, кто любит программировать или управлять по наитию, является документирование. При необходимости можно «опередить события» и сделать экранный прототип, но экранные снимки делаются только ради конкретизации проектной документации. Не отдавайте прототип напрямую программисту, который должен завершать проект. Может показаться, что такой прототип сэкономит время, но он может просто повести программиста неверным путем и спровоцировать фальстарт. Не думайте, что для написания кода бизнес-требований достаточно. Бизнес-требования – только начальный этап разработки документа, позволяющий обрисовать архитектуру, а дальше вы можете говорить о реализации решения в объектах кода. У вас всегда будет искушение, когда поджимает время (а разве бывает иначе?), слепить все «по-быстрому», однако надо быть настоящим счастливчиком, чтобы, не имея четкого плана, создать программный продукт, который можно будет в дальнейшем дополнять и обновлять.

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

 

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

 


Дата добавления: 2015-07-10; просмотров: 115 | Нарушение авторских прав


Читайте в этой же книге: Структура книги | Как привыкнуть к роли руководителя | НАСКОЛЬКО ВЫ КРУТОЙ? | Мало быть крутым – смотри в оба! | Распространенные породы | Редкие породы | Дворняги | Умение обращаться с представителями разных пород | Соревнование по шипению и царапанию | Слава, почет и деньги |
<== предыдущая страница | следующая страница ==>
Мотивирование деньгами| Оценка вашей производительности

mybiblioteka.su - 2015-2024 год. (0.006 сек.)