Последняя лекция. – Безнадёжные проекты. фкн вгу информационные технологии 2012

Последняя лекция. – "Безнадёжные проекты. " )))))

Правило 50 процентов:

• 1) План проекта(временной) - сжат более чем наполовину по сравнению с нормальным расчётом - аналогично если для данного временного промежутка более чем в два раза сокращено число разработчиков.
• 2) Бюджет срезан более чем в два раза относительно нормального.
• 3) Требования к производительности и иным шнягам более чем в два раза.

Это объясняется хотя бы тем , что рабочий день не может быть удлинён более чем в два раза.

Кроме «безнадёжных» существуют ещё два типа проектов, которые едва ли могут быть завершены:

• 1) Система с нечёткими целями.
• 2) Очень сложные системы.

Причины появления безнадёжным проектов:

• 1) «Политика –политика, политика» – это может означать в том числе и многочисленные иррациональные мотивации ,а также логически необоснованные действия – сообщение явно «левых» характеристик своих возможностей с целью получичть заказ - соображения престижа, конкуренция внутри компании и между компаниями.
• 2) Наивные представления руководителей и людей, связанных с составлением плана разработки.
• 3) Наивный оптимизм – типа «мы можем сделать это за выходные» - это также асто связано с неправильной оценкой возможностей .Например в строительстве заранее известно сколько сохнет бетон и т.д. – в программировании же при создании сложных «нетиповых» проектов не сложно ошибиться и переоценить свои возможности.
• 4) Менталитет «первопроходцев» у малоопытных предпринимателей.
• 5) Менталитет «морского корпуса» - «настоящие программисты не нуждаются во сне».
• 6) Высокая конкуренция порождённая глобализацией рынка.
• 7) Неожиданные решения правительства.
• 8) Изменение технологической базы.
• 9) Некий кризис.

Основной способ решения проблем безнадёжных проектов – это :
1) Приоритетность - выбрасываем за борт всё, что не очень важно – оставляем только важное и то ,что легко сделать. Начинаем с функций демонстрирующих основную рабочую идею проекта – программы.

«Лозунги» позволяющие лучше понять проблему управления проектами:

• 1) Написать код программы – это лишь малая часть проекта – но многие этого до сих пор не поймут.
• 2) Самые большие ошибки делаются в первые несколько недель при планировании.
• 3) ПО создаётся командой, а не отдельным сотрудником – если у вас нет хорошей команды - вы не создадите хорошего ПО. В худшем случае такие люди могут даже разрушить команду.
• 4) На первом месте – забота о коллективе.
• 5) Сама по себе задержка проекта ещё не означает ,что команду у вас плохая, но для плохой команды задержка проекта – обычное дело. В связи с этим , если фирма говорит вам , что они крутые и работают и по ночам и по воскресеньям, то это значит, что фирма работает с безнадёжными проектами и постоянно всё «заваливает». При это , безусловно, и в хорошей фирме возникают ситуации, когда необходимо концентрация и приложение усилий.
• 6) Если продукт не оставил у пользователя приятного впечатления и не помог пользователю легко и быстро решить проблемы -маловероятно, что продукт приживётся. Не стоит выпускать на рынок «сырой» проект.

Проблемы , которые необходимо решить ,чтобы преуспеть в управлении проектами:

• 1) Кадры – как найти и удержать нужных специалистов.
• 2) Организация – в частности должны быть ясны роль и обязанности каждого участника группы.
• 3) Инструментарий – ключевые инструменты разработки и способы их использования.
• 4) Тестирование - необходимо наладить процесс тестирования параллельно с разработкой.
• 5) Технология разработки ПО – поддерживать целостность программы и её функционирование на каждом этапе разработке.

Типичные участники:

• 1) Менеджеры проекта
• 2) Программисты
• 3) Разработчики документации
• 4) Тестировщики
• 5) Инженерные психологи – обеспечивают наиболее полный контакт с заказчиками- правильно ставят задачи перед менеджерами и программистами.
• 6) Технологи разработки ПО- хранение , бэкап - система контроля версий – те , кто отвечает в том числе и за администрирования сети , напр, офиса, в котором ведётся разработка.

Качество системы можно оценить по следующим параметрам:

• 1) Скорость работы пользователей
• 2) Количество ошибок - система не должна перекладывать лишнюю нагрузку на человека – должна максимально думать «сама».
• 3) Скорость обучения
• 4) Субъективное удовлетворение - просто «нравится» или нет ))

Этапы планирования:

• 1) Формирование цели =- хочу чая
• 2) Определение общей направленности – надо идти на кухню
• 3) Определение конкретных действий – надо захватить чайник , набрать воды и т.д.
• 4) Выполнение действий = захватываем, и наливаем.
• 5) Восприятие нового состояния системы – смотрим что там получилось –пошёл ли пар.
• 6) Понимание этого состояния – раз пар пошёл – значит закипел
• 7) Оценка результата – смотрим напр – даже если закипел – а достаточно ли мы налили воды? И подходящего ли размера был чайник.

Дизайн интерфейса.
Потеря фокуса внимания:

• 1) На каком шаге остановился?
• 2) Какие команды были даны системе?
• 3) Какие планировались потом?
• 4) Где было внимание на момент отвлечения?

Важно путём проектирования интерфейса ответить на эти вопросы.

Действие может быть либо тонным либо быстрым – то есть на маленькую кнопочку нельзя нажать быстро- не получиться попасть.

Есть правило - где-то 2/3 (до 3/4) окна должно быть занято контролами (элементами), а остальное место – свободно для упорядочивания .

Отрывайте диалоговые окна не в центре экрана, а в области действия пользователя.
Убирайте с экрана диалоги с вопросами на которые в течении 5-ти минут был дан ответ.

Делайте погресс бар – так как иначе можно подумать ,то ваша программа зависла.

Моменты:
1) «кошка на клавиатуре » - необходимо подтверждать важные операции, так как по клаве может просто гулять животное и нажимать на клавиши.