• These are the components of each of our 5 main processes, in total we get at least 20 typical operations or processes that are present in absolutely any modern installation.

     

    Accordingly, it is necessary to think over exactly how this will happen, how these operations will take place. Of course, if we want to somehow maintain control over our installation.

     

    And first of all, how will changes be made to all these components, and how will the current support take place? these operations and processes are key to a running system and are performed most frequently.


  • Any installation that goes beyond the developer's laptop will consist of at least the components shown in the illustration (blue and green stickers).

     

    Each of these components is configured in some way initially, changes are made to it in some way on a regular basis, well, and at some point each of these components will most likely be decommissioned and replaced by some other. Also, in one form or another, there is ongoing support for each of these components - ensuring operability and responding to incidents.


  •  

     

    It would be wrong to say that the review of the goal and objectives of the project is carried out only
    once, immediately upon receipt of the requirements for participation in the competition from the customer.
    Most often, peer review is carried out throughout the preparatory stage, when the level of problem
    statement is insufficient during assessments or decision making. Then you have to clarify with the
    customer the goal and objectives and adjust or even completely revise the concept of the project.

     

    We usually review the goal and objectives by the same person who is entrusted with the development of
    the concept - an experienced system architect. After the review, this person should have sufficient
    information about the customer's expectations about how the developed system will affect its business
    processes, and about the significant limitations associated with the future product's operating environment.
    Restrictions on the timing and budget of the project when developing the concept should not be taken
    into account: the concept is a vision of how the system should function, and not how these functions will
    be implemented. In the future, when assessing the demand and feasibility of the product, restrictions on
    time and budget will be taken into account.


  •  

     

    The purpose of the review is to check how well the formulations are made and, if possible, to clarify them.
    Most likely, if the goal and objectives are expressed in the form of requirements for participation
    in the tender, the contractor will not be able to change the document itself.
    But you can try to enter into
    a dialogue with the customer, which will clarify the direction of the project, narrow the cone of uncertainty
    and stipulate more specific restrictions.
    In this case, it is almost always possible to better understand
    the subject area.

     

    If the project is the first in the history of the relationship with the customer, most likely, the customer
    will not be too talkative.
    First, you are not a performer yet. Secondly, you are taking very busy people
    away from hard work.
    This must be taken into account when making contact with the customer before
    winning the competition.
    Try to ask specific questions that will help you understand how the customer
    sees the future product.
    Remember that you are not working on requirements at this point. Your goal is
    just to get enough information to assess the prospects of the project and decide on your participation in
    the competition.
    And no more






    Suivre le flux RSS des articles
    Suivre le flux RSS des commentaires