Как стоит работать над собственным большим проектом?

Question

[Дмитрий]

Добрый день.
Пришла в голову идея реализовать информационную систему для предприятия, где я работаю. Задача большая, с какого края подступиться - непонятно. Был опыт работы над небольшими и средними проектами и в составе групп, где было очевидно что делать и как работать, а тут все сам. Хочется начать самому, а там будет видно - может кто и подтянется.
Что вы посоветуете для самостоятельной работы над большими и сложными проектами (скажем, уровня, которого вы раньше не достигали)? На что уделить стоит внимание, что важно, а что нет. Узнал недавно про метод "Прогрессивного Jpeg" (https://habrahabr.ru/post/90459/), как вы думаете, он может быть полезен?
Спасибо.

Comments

[Евгений]

По-моему, это называется Agile

[Дмитрий]

Да, спасибо. Изучу.

[Евгений Шатунов]

Узнал недавно про метод "Прогрессивного Jpeg"

Про прогрессивный jpeg - это просто автор не знал общей терминологии. Обще название метода: метод металлического отжига.

По своей сути - это метод прогрессивной декомпозиции задачи, при котором комплексность задачи выражает ее близость к "нормальной температуре".
Советую, в рамках общего развития кругозора, закинуться вот таким материалом. Не смотри что это gamedev.ru, там про шаблоны проектирования верхних уровней, а не про игры. Советую обчитаться и начать искать более информативные источники по вычитанным терминам. Далее, будет полезно прочитать хотя бы второй том GoF (если, конечно, не читал). Лучше бы выштудировать оба тома, но это уже если есть время...

Я смотрю, советчиков у тебя буквально море и все советуют очень годные штуки, так что я обойдусь без ответов, простым уточнением к твоему вопросу. :)

[Константин Нагибович]

Пришла в голову идея реализовать информационную систему для предприятия, где я работаю.

Предприятию эта система точно нужна?

[Дмитрий]

Скорее всего нет. Но мне хочется самому сделать что-то полезное и получить навыки, которых у меня нет. Да и я привык тут, что если тебе не надо - то никому не надо.

[Константин Нагибович]

Дмитрий Дмитриев, пожалейте свое время - работа в стол это не лучший вариант приложения своих усилий.

[Дмитрий]

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

[Максим Тимофеев]

Скорее всего нет.

Но мне хочется самому сделать что-то полезное

Так если не нужна, значит Вы делаете бесполезное.

А если это ради опыта, тогда не стоит думать, что это купят потом. Делайте постепенно, набивайте шишек и т.д.

[dom1n1k]

лучшее обучение - это реально работающий проект

Оно-то верно, но ваша система реально работать не будет. Даже если предположить, что вы осилите и напишете код - она помрет на этапе внедрения. Никто не захочет ломать привычные рабочие процессы ради неведомой поделки.

[Андрей]

автор вали с работы, в твоей ситуации гнилое дело. либо убеждай руководство выделить человеко-денежные ресурсы достаточные для того что бы над проектом работало чуть больше чем 1 человек

[Alexander]

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

Если есть действительно большое желание, что-то делать для саморазвития. То возьмите какую-то НЕ глобальную задачку, а маленькую, упрощающую жизнь одному сотруднику или небольшого отдела. И автоматизируйте её. Попутно вникнув в бизнес процесс и бизнес логику этого отдельного участка. Потом другого и так далее. Маленькими шажками. Потом уже, спустя пол года-год, сможете задуматься о чём-то большем. Только, святой Ктулху забери Билла, не сами придумывайте эту задачку и её реализацию, а вместе с тем звеном для которого делаете. Научитесь взаимодействовать с "заказчиком" и составлять ТЗ, а потом и внедрять да согласовывать принятие теми кому с этим вашим творение и работать. Думаю выползет не мало уточнений и переделок. Если созданное будет полезным, то вам будут предлагать улучшить или развить его. Возможно появится взаимодействие с другими отделами или сотрудникам, а может и сторонними сервисами...

Answer 1

[Максим Тимофеев]

Узнал недавно про метод "Прогрессивного Jpeg", как вы думаете, он может быть полезен?

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

Что вы посоветуете для самостоятельной работы над большими и сложными проектами

Самое полезное при такой работе это мозг и опыт, причем недостаток одного из них надо компенсировать переизбытком второго.

Задача большая, с какого края подступиться - непонятно.

Начните с проектирования. Судя по всему Вы даже не представляете, что планируете делать, а без этого не стоит начинать.

Answer 2

[Дмитрий Ковальский]

Звучит как гигантский чугунный велосипед. Можно называть как больше нравится - прогрессивный Jpeg, MVP или еще как-то.
Большой проект это over9000 маленьких и средних проектов.
По факту вам надо реализовать несколько бизнес-процессов(хоть с 1 начните. авторизация и 1 бизнес-процесс) и затем на базе имеющейся архитектуры наращивать функционал. Но забегая вперед скажу что примерно на 3-4 шаге вы споткнетесь о то что в имеющейся архитектуре новый функционал чужероден.

А к этому еще надо добавить что в больших системах есть не только разработка, но и поддержка. У вас банально рук не хватит и или система встанет колом в развитии пока вы баги правите, либо система погрязнет в багах.

Comments

[Дмитрий]

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

Answer 3

[Сергей Нижний Новгород]

Опыт подсказывает ряд вещей:

1) Приниматься за большую программу в твоих условиях - глупо.
- такие системы делаются годами
- внедрение таких систем обходится очень дорого
- без решения "сверху", такие штуки не проходят

т.е. даже если ты осилишь такую систему (что вряд ли - говорю честно), то ты с ней ничего не сможешь сделать. Так как предприятию выгоднее и надежнее работать с каким-нибудь центром внедрения 1с + другой стаф, чем с каким-то мальчиком.

2) Если у нет четкого плана, что делать с этой программой (а его у тебя нет), то ты выгоришь за 3-6 месяцев, и у тебя будет просто воспоминание о том, что ты там что-то колупал. Как портфолио - это использовать вряд ли получится.

3) Продукты обычно хорошо идут, когда ты его быстро доводишь до рынка + получаешь фидбек от юзеров.

Другими словами, тебе лучше выбрать какой-то проект, который ты железно сможешь реализовать за 6 месяцев (максимум) и сможешь его самостоятельно вывести на рынок. Тогда дело в теорию может пойти, иначе забей.

4) А где экспертиза, дружок? Ты не сможешь сделать систему автоматизации для предприятия, если ты не будешь знать все его бизнес-процессы. И не просто знать их, а понимать их на 100%.

Answer 4

[Игорь]

Я - гадалка 80 уровня, подсказываю вам:
реализуйте какую-нибудь одну небольшую функцию системы, но так чтобы потом функционал можно было расширять, и постепенно добавляйте новые функции.

Answer 5

[asd111]

Сначала нужно выбрать стек технологий. LAMP или что нибудь ещё что вы лучше знаете.
Затем нужно всё спроектировать. Т.е. расписать все урлы и что они будут делать.
Потом проектируем модели т.е. БД, чтобы точно знать что и как будет храниться в базе.
По ходу дела пишем документацию по урлам и БД.
Пишем тесты.
Пишем функционал и документацию по функционалу.
Без документации и без тестов в большом проекте будет очень неприятно работать если появится хотя бы один новый разработчик.
Маленькие проекты можно делать без тестов и без документации.

Answer 6

[awesomer]

Пришла в голову идея реализовать информационную систему для предприятия, где я работаю. Задача большая, с какого края подступиться - непонятно.

"пришла в голову идея для предприятия реализовать"?
а ему это надо?

Забей.
Без серьезной поддержки предприятия - быстро выгоришь.

Answer 7

[xmoonlight]

План создания ТЗ и этапы проектирования сайта.

Answer 8

[vanyamba-electronics]

Представь, что тебе нужно написать продукт, который твоё предприятие у тебя купит.
Для этого тебе нужно будет нанимать программистов, которые будут писать отдельные модули. Тебе нужно будет ставить им задачу.
Погугли "как написать тз".

Answer 9

[rango]

Начинать самостоятельный проект лучше в качестве продакт-менеджера, а затем переходить к роли проект-менеджера

Очень не рекомендую начинать большой проект с ТЗ, с прототипирования и уж тем более с выбора стека технологий, как здесь советуют. Это путь к мёртво-рождённому проекту, который будет либо не нужен, либо не получится завершить.

1. сначала подумать о концепции, о пользователях, о ресурсах и поддержки внутри твоей компании.
Рекомендую к прочтению книгу На крючке. Как создавать продукты-хиты Можно попробовать найти краткое изложение.

2. Ближе к финалу предпроектных работ начни декомпозировать проект на более мелкие проекты, те в свою очередь на составные задачи, а составные задачи на задачи и тп. Самым мелким должны быть задачи которые можно сделать за один раз и которые можно оценить по времени или стоимости с неплохой точностью. На последних этапах хорошо работает привлечение экспертов.

Answer 10

[NeKt0]

Декомпозия поможет.