How should you work on your own big project?

Question

Project management

Good afternoon.
I came up with the idea to implement an information system for the enterprise where I work. The task is big, from which edge to rise - it is not clear. There was experience of working on small and medium projects and as part of groups, where it was obvious what to do and how to work, but here everything is on my own. I would like to start on my own, and there it will be seen - maybe someone will catch up.
What would you recommend for working independently on large and complex projects (say, a level that you have not reached before)? What to pay attention to, what is important and what is not. I recently learned about the "Progressive Jpeg" method ( https://habrahabr.ru/post/90459/), do you think it can be useful?
Thank you.

Answer 1

I recently learned about the "Progressive Jpeg" method, do you think it can be useful?

Do you really think that without knowing the essence of the project, someone other than a fortune teller of the 80th level can answer something? You still ask on what PL to implement. There are no methods that work equally well in all conditions. And most importantly, you need to understand it, because this principle, as a rule, is completely misinterpreted.
The most useful thing in such work is the brain and experience, and the lack of one of them must be compensated by an excess of the second.
Start with design. Apparently you have no idea what you plan to do, and without it you should not start.

Answer 2

Sounds like a giant cast iron bike. You can call it whatever you like - progressive Jpeg, MVP or something else.
A big project is over9000 small and medium projects.
In fact, you need to implement several business processes (at least start with 1. authorization and 1 business process) and then increase the functionality based on the existing architecture. But looking ahead, I’ll say that at about 3-4 steps you will stumble over the fact that in the existing architecture the new functionality is alien.
And to this we must add that in large systems there is not only development, but also support. You simply don’t have enough hands and either the system will stand up in development while you correct bugs, or the system will become mired in bugs.

Answer 3

Experience suggests a number of things:
1) To take on a big program in your conditions is stupid.
- such systems have been made for years
- the implementation of such systems is very expensive
- without a decision "from above", such things do not work,
i.e. even if you master such a system (which is unlikely - I’m honest), then you can’t do anything with it. Since it is more profitable and more reliable for an enterprise to work with some 1c + other staff implementation center than with some boy.
2) If you don’t have a clear plan for what to do with this program (and you don’t have one), then you will burn out in 3-6 months, and you will just have a memory that you were doing something there. As a portfolio - this is unlikely to be used.
3) Products usually do well when you quickly bring it to the market + get feedback from users.
In other words, you'd better choose some project that you can iron out in 6 months (maximum) and you can bring it to the market yourself. Then it can go into theory, otherwise forget it.
4) And where is the expertise, my friend? You cannot make an automation system for an enterprise if you do not know all its business processes. And not just to know them, but to understand them 100%.

Answer 4

I am a level 80 fortune teller, I suggest you:
implement some one small function of the system, but so that later the functionality can be expanded, and gradually add new functions.

Answer 5

First you need to choose a technology stack. LAMP or whatever else you know best.
Then you need to design everything. Those. describe all the urls and what they will do.
Then we design models i.e. DB to know exactly what and how will be stored in the database.
Along the way, we write documentation on urls and databases.
We write tests.
We write functionality and functionality documentation.
Without documentation and without tests in a large project it will be very unpleasant to work if at least one new developer appears.
Small projects can be done without tests and without documentation.

Answer 6

I came up with the idea to implement an information system for the enterprise where I work. The task is big, from which edge to rise - it is not clear.

"I came up with an idea for the enterprise to implement"?
does he need it?
Do not mind it.
Without serious support of the enterprise, you will quickly burn out.

Answer 7

Plan for the creation of technical specifications and stages of site design .

Answer 8

Imagine that you need to write a product that your company will buy from you.
To do this, you will need to hire programmers who will write separate modules. You will need to assign them a task.
Googled "how to write tz".

Answer 9

It is better to start an independent project as a product manager , and then move on to the role of a project manager.
I do not recommend starting a large project with technical specifications, with prototyping, and even more so with choosing a technology stack, as advised here. This is the path to a dead-born project that will either not be needed or will not be completed.
1. first think about the concept, about users, about resources and support within your company.
I recommend reading the book On the Hook. How to create hit products You can try to find a summary.
2. Closer to the end of pre-project work, start decomposing the project into smaller projects, which, in turn, into compound tasks, and compound tasks into tasks, etc. The smallest should be tasks that can be done at one time and that can be estimated in terms of time or cost with good accuracy. At the last stages, the involvement of experts works well.

Answer 10

Decomposition will help.