To be in time as soon as possible - development by stages

    They give us tasks and set deadlines. Sometimes the timing is not realistic. A possible reason is that the task was not designed, not broken down into stages. It is difficult to set deadlines based only on intuition and experience.

    As a site developer, I come across such tasks. Dates for these tasks are set based on business requirements. I’ll share my experience on how, under tight deadlines, I managed to successfully implement the requirements of the business.

    I give advice that I am guided by myself and which have helped me more than once. Each statement requires discussion, reflection and criticism.
    The tone of the article seems categorical. Immediately apologize for that. For brevity, I omitted the phrases “I think,” “I suppose,” and so on.

    I will share experience based on an example. We will come up with the following problem. Numbers and terms are conditional.

    We are developing an e-commerce site that sells children's toys. Payment only in cash. We realize non-cash payment using:
    • PayPal
    • Yandex.Money;
    • QIWI Wallet;


    The manager set the deadline - a week.
    You rummaged in the finished code, studied architecture, thought about these requirements. They remembered that 5 more tasks were hanging on us that nobody had canceled. And they realized that you could not cope in a timely manner.
    You went to the manager, explained the situation. The manager replied like this:
    • Urgent tasks, have time to do
    • Ok, I will suspend 2 tasks. Perform the remaining 3 tasks in parallel.
    • Ok, I’ll extend this task for 1.5 weeks


    These options do not suit you. Not enough time. You are at a dead end and thought about such solutions:
    • get to work early.
    • stay longer at work.
    • You are already constantly lingering, you have to linger 2 times longer.


    How to be?
    Here the book of Stephen R. Covey “7 Skills of Highly Effective People” will help .

    1. Be proactive
    2. Begin, imagine the ultimate goal.
    3. Do what you need to do first
    4. Think in the spirit of won - won


    Be proactive - suggest a solution to your problem. Some managers even have a corresponding sign “Do not enter without suggestions” on the door.

    Starting, imagine the ultimate goal - the ultimate goal here is not to solve the problem, but to satisfy the current needs of the business.
    First do what you need to do first - this is the solution to the problem. We will independently find out the priorities and divide the task into stages!

    Think in the spirit of winning - winning - phasing will allow you to release a finished function even earlier than the deadline. The manager will be more willing to accept the proposal about the stages, if he receives the necessary function early.

    Recall also the definition of Scrum methodology.- this is a set of principles that allows hard-fixed and small-time iterations to provide the end user with working software with new features for which the highest priority is defined.

    Actions are as follows:
    1. We break the task into subtasks - a proactive approach. Do not ask the manager, do it yourself.
    2. We determine the priorities of each subtask.
    3. We break the task into stages.
    4. Together with the manager we adjust the terms.
    5. We solve the big task in stages.


    The subtasks were as follows:
    1. implement paypal,
    2. realize yandex money,
    3. implement QIWI wallet


    The manager adjusts the list of subtasks. Priorities were set based on the percentage of customers who would like to use payment systems. Received such stages:
    1. Yandex.Money 60% of users
    2. QIWI Wallet 30% of users
    3. PayPal - 10% of users.


    Together with the manager, we set the following dates:
    1. Yandex.Money - 3 days
    2. QIWI Wallet - 4 days
    3. PayPal - 2 days.


    Results:

    It turned out that we are not going to solve the problem in a week, but much earlier we will release a useful function for customers.

    Partitioning I showed on a simple task. In practice, tasks are much more difficult, there are more stages, managers do not agree with the proposal. To justify, we use UML diagrams.

    The diagrams clearly show that the task is complex, each element contains many details and features. Based on such a clear description, you justify why it is not possible to realize the task in a timely manner.
    The deadlines for individual elements are estimated more accurately than the deadlines for the implementation of a large task.

    Conclusions:
    1. Instead of excuses and complaints about inadequate terms, you proposed a constructive solution - to break the task down into stages.
    2. With the help of diagrams, you have proved the complexity of the task and justified that this task is divided into stages.
    3. The manager is satisfied - the first release (stage 1) took place ahead of schedule, useful documentation appeared.
    4. You have improved communication skills with management, avoided inadequate deadlines and large overhauls.
    5. You have improved design and documentation skills by providing some ready-made solution that has been improved by an experienced colleague.
    6. The work became more interesting - you learned additional information about the project (user priorities)


    Conclusions in the form of tips:
    1. Come with a ready-made solution. You will receive an additional bonus - errors are corrected.
    2. Do not spend a lot of time splitting a task into subtasks. The point is to prepare a draft for discussion.
    3. Do not start coding. Even if the manager designed and drew the diagrams before you. Sketch your own interpretation of the task. This will clarify unclear points and save you a lot of time.
    4. Try prioritizing yourself.
    5. Design yourself and do not rely on the fact that the manager or team leader completely controls and corrects your steps. They don’t have time for this.


    References:


    PS
    1. Waiting for your links and useful tips in the topic - add to the article
    2. If the topic is interesting, I’ll write an article where, using a complex example, I will analyze the process of designing and dividing a task into stages.

    Only registered users can participate in the survey. Please come in.

    Do you have to not only code, but also design?

    • 19.6% Yes, because design is my primary responsibility 11
    • 62.5% I code and design 35
    • 16% Mostly coding, sometimes involved in design 9
    • 0% Only encode 0
    • 1.7% Other 1

    Also popular now: