Как правильно составить план разработки крупного проекта?
Как правильно составить план разработки проекта? (рекомендовано новичкам, желающим разработать крупный проект)
Начну, пожалуй, с небольшого вступления. Зачем вообще это нужно - составлять план разработки? Люди, уже работавшие над проектами, отнимающими большое количество времени, знают, насколько этот момент разработки важен. Новички же, обычно, не понимают этого, и сильно ошибаются, пропуская эту стадию разработки. При разработке больших проектов, вы можете легко запутаться, что вы сделали, а что еще нет; что нужно сделать обязательно, а что желательно; что нужно сделать сразу, а что потом. Так вот верно написав план предстоящей работы, вы решите все эти проблемы сразу. В этой статье я опишу способ создания плана разработки.
Итак, приступим. Что же лежит в основе любого проекта? Несомненно, это основная идея, фундамент будущего проекта. На ее же основе строится и план разработки, поэтому план для каждого проекта свой, он уникален. К примеру: идея создать новый браузер. Следующий этап - определение целей проекта. Какие цели вы преследуете, создавая проект? Постарайтесь тщательно продумать цели проекта, от этого зависит, что вы получите после завершения проекта. Например, новая игра в первую очередь должна доставлять удовольствие конкретному типу игроков, скажем, любителям РПГ, а уже во вторую очередь - принести прибыль. Далее следует определить основные моменты разработки проекта и его особенности. Например, если вы разрабатываете программу, то на этом шаге вы должны определить, что самое главное - работоспособность, графика, звук, дизайн или что-то еще. Это тоже важный этап, постарайтесь не ошибиться. Затем нужно определить, что вы будете создавать сначала. Этот пункт напрямую зависит от предыдущего. Например, если "фишка" вашей программы - неповторимый дизайн, то и разработку нужно начать с проектирования дизайна. Конечно, нужно расположить все основные этапы предстоящей разработки по мере уменьшения их важности в будущем проекте. Следующий шаг - определение примерных сроков разработки. Попытайтесь определить, сколько времени у вас уйдет на разработку каждой из основных частей проекта. Это не так важно, но может помочь в дальнейшем планировании работы. Теперь время за разбитием основных стадий разработки на более мелкие. К примеру, при разработке прикладной программы, этап разработки программной части можно разбить на следующие части: выполнение конкретной задачи, программное управление графикой и звуком, обработка ошибок, обратная связь с автором, система помощи (если она не оформлена в виде файла помощи) и т.п. Постарайтесь сделать это тщательно, это упростит разработку проекта и сделает его более качественным и продуманным. Теперь пора разбить все это на более мелкие кусочки, чем на предыдущем этапе. Здесь следует выполнить тщательное разделение. Например, будущий дизайн на этом этапе должен быть разбит на отдельные картинки, которые потом нужно будет нарисовать и, скорее всего, программно соединить, образовав графическую оболочку программы. Этот этап, думаю, наиболее важен. Ну а теперь, самое сложное: определить, сколько времени и какие дни нужно уделить разработке отдельных частей проекта. Отталкиваясь от предыдущих этапов планирования, постарайтесь рассчитать требуемое время для выполнения проекта. Это очень важно, так как, если вы будете не укладываться в срок, план придется перестраивать, а если времени будет слишком много - вы расслабитесь, и, возможно, потеряете проект. Однако время для отдыха должно оставаться, иначе вы быстро устанете от проекта и, возможно, бросите его. Повторим основные этапы написания плана: 1.) идея проекта; 2.) цели проекта; 3.) основные моменты разработки; 4.) определить самое важное; 5.) примерные сроки разработки; 6.) разбитие основных моментов на меньшие части (в команде - распределение ролей между разработчиками); 7.) еще более мелкое разбитие (в команде выполняется отдельными людьми в соответствии с их специальностью); 8.) определение более точных сроков (в команде - все согласуются друг с другом, дабы не нарушать целостность коллектива и укладываться в установленный заказчиком срок). Итак, если вы все сделали правильно, у вас должен получиться отличный план, следуя которому, вы создадите именно то, что хотели. И напоследок: уделите созданию плана как минимум час, а лучше несколько. В зависимости от размера проекта, для составления плана может потребоваться до нескольких дней - но цель оправдывает средства. Стоит отметить, что составление плана особенно важно для команд разработчиков - кто и что должен будет сделать. В данном случае, руководитель команды обязан составить план только до разделения основных частей, более мелкое планирование должно совершаться участниками команды. Планирование задач команды - залог ее успеха, без этого команда просто развалится.
Удачи вам в разработке ваших проектов! С вами был Tim Kruz, ждите новых статей.
Также если вы считаете, что данный материал мог быть интересен и полезен кому-то из ваших друзей, то вы бы могли посоветовать его, отправив сообщение на e-mail друга:
Игровые объявления и предложения:
Если вас заинтересовал материал «Как правильно составить план разработки крупного проекта?», и вы бы хотели прочесть что-то на эту же тему, то вы можете воспользоваться списком схожих материалов ниже. Данный список сформирован автоматически по тематическим меткам раздела.
Предлагаются такие схожие материалы:
Если вы ведёте свой блог, микроблог, либо участвуете в какой-то популярной социальной сети, то вы можете быстро поделиться данной заметкой со своими друзьями и посетителями.
Это конечно все хорошо. Но ведь иногда жесткие рамки времени могут навредить,порою даже не тем что короткие.И я говорю о отдельных людях в команде,а не проэкте.Это зависит от темперамента,характера и вообще от того что происходит с человеком в его повседневной жизни. Равно как и наоборот,для творческой деятельности есть такой момент,если человек споймает волну и от работы у него будет разве что физическая усталость.С одной стороны это также свобода,но с другой это позволит человеку работать без излишних передышек и даже с большим эффектом. Работа может быть стимулом к работе. Но все же главное здесь это то что руководитель играет большую роль.Если он и занимается какой то частью создания игры,ему все равно нужно больше уделять внимания руководству. Человеческие ресурсы неограничены и он должен должен раскрывать их потенциал. И ещё команде нужен психолог.Даже если их 10-15 человек он уже требуется.Дело вовсе даже не в микросоциальном аспекте,дело как раз в том что потенциал любого человека мало расскрыт,но к тому же ещё хуже то,что есть множество негативных факторов,которые мешают использовать уже открытый потенциал,это может быть настолько банально,что человеку не нравится их чат и он хотел бы общаться через скайп,или наоборот.Просто ему неохото включать браузер или он вообще с телефона общается.Таких мелочей может быть много и они могут сильно влиять на работу.Кроме этого если руководитель легко справляется со своей работой,можно также сделать чтобы монотонная работа не была скушной,не надоедала.Определив что должен делать человек,можно поддерживать его в тонусе,давая возможность работать поочереди с различными "темами" его работы.Но пускать на самотек достаточно рискованно,человеку может стать неинтересно,так как в его работе перестанет появляться новое,и он будет хуже работать.Руководитель должен общаться со всей командой и по возможности расслаблено,не навязчиво и ни в коем случае не заставлять(к отдельным личностям не применимо,к кому сами поймете) ),и исходя из настроения и статистики работы "на глаз"(не на глаз если в команде есть психолог,и функции руководителя делятся хотябы на двух людей.для большой команды нужны отдельные люди которые будут вести статистику) должен менять задание.
Это лишь другая стратегия,не нужно воспринимать буквально.
Ну и самое главное,эмоции это двигатель творчества,нужно поддерживать хорошее настроение команды,показывать доброту и дружбу,не нужно что бы люди "приходили на работу" и абстрагировались от жизни,все равно из головы семью не выкинешь и пусть лучше каждый момент жизни будет в пользу вашему проэкту.Просто не ищите пользы,а видьте хорошее во всем. Ab imo pectore,Fabervox.(С уважением,Я.)
План? А зачем тогда вам дорогие ДизДоки от 1С? По моему они не очень и плохие если ориентироваться на их структуру. И не надо заморавчиваться на уже понятные довольно-таки темы.
-1
Слишком мало для статьи.
План? А зачем тогда вам дорогие ДизДоки от 1С? По моему они не очень и плохие если ориентироваться на их структуру. И не надо заморавчиваться на уже понятные довольно-таки темы. 
хорошая статья.
Я бы всё это записал немного по-другому,но суть конечно остаётся такой же!
Хорошая статья) Сам столкнулся с такой проблемой и подтверждаю слова автора. План нужен 
