Последняя лекция. – Безнадёжные проекты. фкн вгу информационные технологии 2012
Primary tabs
Forums:
Последняя лекция. – "Безнадёжные проекты. " )))))
Правило 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) «кошка на клавиатуре » - необходимо подтверждать важные операции, так как по клаве может просто гулять животное и нажимать на клавиши.
- Log in to post comments
- 2430 reads