Cg&web 2010 Despark Dipchikov Project Management

1,143 views

Published on

Stoyan Dipchikov from Despark digs deep into numbers, charts and issues about managing web projects.

Published in: Design, Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,143
On SlideShare
0
From Embeds
0
Number of Embeds
56
Actions
Shares
0
Downloads
25
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Cg&web 2010 Despark Dipchikov Project Management

  1. 1. Здравейте, аз съм Стоян Христов Дипчиков. В следващия час ще ви запозная с проблемите на проджект мениджмънта и планирането.
  2. 2. Успеваемост на проекти 35% succeded 65% провалени (19% провалени + 46% извън бюджет и срокове) 1. 65% от софтуерните проекти са неуспешни или проблемни (Standish Group) 2. 25-40% от работа по софтуерни проекти се изхвърля и прави наново (Carnegie Mellon) 3. 50% от проектите биват изваждани от експлоатация веднага след инсталацията си (Gartner)
  3. 3. Бизнес анализ и успеваемост 35% успешни 65% провалени (19% провалени + 46% извън бюджет и срокове) 1. 40% от проблемите се откриват от крайните потребители (Garner) 2. Неправилно дефиниране на изискванията води до 66% от провалите (Forrester Research) 3. 60-80% от провалите на проекти са резултат от неправилно събиране и управление на изискванията (Meta Group)
  4. 4. Развитие на проекта и дефекти Release Тест Реализация Дизайн Изисквания Заключения 1. Web сайтовете се разработват, за да изпълнят набор от изисквания 2. По-голямата част от бъговете се откриват след реализацията на проекта 3. Изискванията са главния източник на дефекти в проекта Откриваеми на бъгове 40-50% Цена на промените Много Висока Откриваеми на бъгове 15-50% Цена на промените Висока Откриваеми на бъгове 10-15% Цена на промените Средна Откриваеми на бъгове 5-10% Цена на промените Ниска Откриваеми на бъгове < 5% Цена на промените Ниска
  5. 5. Защо се провалят проектите? Прибързване с започването на кодирането и дизайна Грешна оценка на проекта Не се предвиждат бъдещите дефекти Някои от лошите навици на програмистите ;) Омагьосания кръг, в който поставяме софтуерните тестери
  6. 6. Как да осигурим успеха на проекта си? Поддържайте прозрачността в проекта Всички в екипа са равни Имайте доверие на екипа си! Не пренебрегвайте бумащината Проверявайте често проекта, пишете отчети често
  7. 7. SDL (Software Development Lifecycle) Waterfall Agile Rup Изисквания Дизайн Реализация Тест Поддръжка Начало Дневни промени Удобрени промени Итерация Проект Начална подготовка Уточнения Изграждане Миграция
  8. 8. Планирането на проект?!? Планирането на проект?!? Какво представлява планирането на проект? Начална фаза на планирането 1. Обхват на проекта (Scope) - Засегнатите лица по проекта / Stakeholders (Лице за контакт) и Ресурси (Вашите колеги + технически и други нужди за проекта) 2. Проблеми за решаване и анализ на рисковете 3. Интервюта с клиента и събиране на изискванията
  9. 9. Техническо задание и wireframes Няма общо приета структура за технически задания. Моят пример: 1. Кратко описание на проекта и неговите цели 2. Използвани технологии 3. Засегнати лица 4. Речник 5. Описание на основните модули 6. Приложения (Flow charts, диаграми и описание на алгоритмите и т.н.) Wireframes (скици на проекта) 1. Защо са ни скици? 2. Начини за създаване на Wireframes: На ръка или чрез специализиран софтуер (Axure, Adobe Fireworks) 3. Не се увличайте в дизайн на wireframe-ите wireframes
  10. 10. Оценка на проекта 1. Защо ни е нужна оценка? 2. Как процедираме в Despark? 3. Документирайте сроковете, който сте решили както и причината за определянето им, за да може после да ги съпоставите с реалните резултати и да ги анализирате
  11. 11. График на проекта 1. Разбиване на проекта на малки под задачи, като за основа ползваме разписаните задачи от предната фаза на оценката 2. Труд за разработка на задача с/у Време (Effort vs. Duration) 3. Максималното време което може да се просрочи един таск без да се отрази на проекта. 4. Разпределяне на ресурсите по задачите 5. Буферни таскове (Buffer tasks) 6. Milestones и предварително насрочени срещи с клиентите 7. Разработка на зависимостите м/у тасковете 8. Проверка на графика 9. Софтуери за Project Management (MS Project, Merlin) 10. Примери – DoBand (Agile), MerchantGuard (малко milestones), the360 (много milestones и предварително насрочени срещи)
  12. 12. Срещи и комуникация с клиентите 1. Не забравяйте, че те са един от ключовете към успешен проект 2. Максимален брой Face-to-Face срещи 3. Подготвяйте си въпроси преди всяка среща и помислете какво биха Ви питали 4. Не ограничавайте комуникацията си с клиента само в срещите 5. Софтуери и online продукти помагащи за комуникацията по време на проекта: 6. Basecamp, Wrike, Lighthouse 7. Чести и ревюта и отчети са добра практика Няколко съвета Прозрачност Гледайте да сте максимално отзивчиви и ги накарайте да почувстват, че са приоритет номер 1 Не прекалявайте с компютърните термини, говорете на разбираем за тях език Бъдете активната страна в дебатите
  13. 13. Промени. Анализ и оценка на промените Промени. Анализ и оценка на промените Това е неизбежен момент, бъдете готови за него Анализ и оценка 1. Колко време би отнела 2. Как това ще се отрази на графика 3. Колко би струвала на клиента 4. Дали всъщност тази промяна въобще е нужна и можем ли да минем без нея 5. Обсъдете промяната с колегите си, работещи по проекта, за се види и тяхното мнение по въпроса. Имайте предвид 1. Програмистите не обичат промените! 2. Програмисткия неписан закон „Ако нещо работи, не го пипай!” ;) Заплащането на промените 1. Не издребнявайте в изискванията си за заплащане на всичко 2. Но следвайте стриктно политиката си относно заплащането на промени
  14. 14. Дизайн и програмиране 1. Pair programming 2. Програмистите не могат да тестват качествено собствения си код, вложете малко допълнителен ресурс в тази насока 3. Задължително е и клиента да се намеси в тестовете 4. Bug tracking системи – Lighthouse, Mantis 5. Използвайте SVN
  15. 15. Благодаря за вниманието!

×