Vous êtes sur la page 1sur 23

A Business Analyst is a business problem solver, capable of analyzing the business to identify problems and/ or opportunities and to define

solution characteristics. A Business Analyst can be a liaison between the business and technical worlds.They provide the process, questions, and techniques to efficiently extract the information needed from the Business Users for successful application development projects. A Business Analyst can also be an integral part of strategic planning, business innovation, or reengineering effort to help select the right projects and/or facilitate the analysis of what needs to be done to bring the business (or part of it ) to a desired future state. Why Business Analysis The increased pressure to innovate, do more with less, and succeed in environments with short attention spans has organizations scrambling to build business analysis capabilities. Innovation requires:

Aligning business strategy with enterprise goals. Breaking down silos to create integrated processes and data across organizational and political boundaries. Architecting processes, systems, and information to work together in harmony. Optimizing technology to create new value and services for both internal and external customers.

Business analysis is following the exponential growth of project management as the new prerequisite, not just for project success, but career success. Role of BA in company

In other organizations, business analysts have an intimate understanding of the business but a limited knowledge of computer systems and application system architectures. The business analyst of greatest value to an organization, however, is a generalist who can function competently in many diverse roles. Such individuals typically have a broad educational background, a diverse skill set and a wide range of work experience in different jobs and industries. They are able to see the big picture as well as the technological and architectural barriers and enablers. Business analysts must be comfortable working with "specialists" in diverse roles and to understand the business from many diverse perspectives.

Business Analyst Skills


Business Planner Organization Analyst Project Manager Systems Analyst

Financial Analyst Technology Architect

Data Analyst

Subject Area Expert

Application Architect Process Analyst

Application Designer

Archietect Software architect is a computer programmer who makes high-level design choices and dictates technical standards, including software coding standards, tools, and platforms.

The role of software architect generally has certain common traits: Architect makes high-level design choices much more often than low-level choices. In addition, the architect may sometimes dictate technical standards, including coding standards, tools, or platforms. Software architects may also be engaged in the design of the architecture of the hardware environment, or may focus entirely on the design methodology of the code. Architects can use various software architectural models that specialize in communicating architecture.
Other types of IT-related Architects

Other similar titles in use, but without consensus on their exact meaning, include:

Solutions Architect, which may refer to a person directly involved in advancing a particular business solution needing interactions between multiple applications. May also refer to an Application Architect.

System Architect (singular), which is often used as a synonym for Application Architect. However, if one subscribes to Systems theory and the idea that an enterprise can be a system, then System Architect could also mean Enterprise Architect. Systems Architect (plural), which is often used as a synonym for Enterprise Architect or Solutions Architect.

Archietect

diagram summarises this.

The first part of the role is about managing the non-functional requirements. Non-functional requirements need to be specific, measurable, achievable and testable if we are going to satisfy them, plus we need to make sure that all of the important non-functional requirements are taken into account. This includes the common runtime characteristics such performance, scalability, availability and security through to the non-runtime characteristics such as audit, extensibility, internationalisation and localization Architecture definition is about introducing structure, guidelines, principles and leadership to the technical aspects of a software project

Technology selection Technology selection is all about managing risk; reducing risk where there is high complexity or uncertainty and introducing risk where there are benefits to be had. All technology decisions need to be made by taking all factors into account, and all technology decisions need to be reviewed and evaluated. This includes all of the major building blocks for a software project right down to the libraries and frameworks being introduced during the development. Somebody needs to take ownership of the technology selection process and again it should be the architect. If you're defining an architecture, you also need to be confident that the technology choices being made are the right ones. The architect should own the technical risk and the technology selection. Architecture evaluation architecture works if it satisfies the non-functional requirements, provides the necessary foundation for the rest of the code and works as the platform for solving the underlying business problem. One of the biggest problems with software is that it's complex and abstract. The result of this is that it's hard to visualise the runtime characteristics of a piece of software from UML diagrams or even the code itself. Furthermore, I don't always trust myself to get it right first time. Throughout the software development lifecycle we undertake a number of different types of testing in order to give us confidence that the system we are delivering will work when rolled out Architecture collaboration It's unusual for any software architecture to reside in isolation and there are a number of people that need to understand it. This ranges from the immediate development team who need to understand and buy in to the architecture, right through to the extended team of those people who will have an interest in the architecture from a security, database, operations, maintenance or support point of view. Somebody needs to take ownership of collaborating with these stakeholders and sharing the architectural vision to ensure that the architecture will successfully integrate with its environment. Again, this falls squarely within the role of the architect. As an architect, you need to make sure that the architecture you have defined is understood by everybody involved with making it a reality. Ownership of the bigger picture somebody needs to own the bigger picture and sell the vision throughout the entirety of the software development lifecycle. More often than not, an architecture is defined and then passed over to a development team, effectively treating software development as a relay sport. This is counterproductive because a software architecture needs to be taken care of. Somebody needs to look after it, evolving it throughout the project if necessary. Somebody needs to take ownership of that bigger picture throughout the project and they also need to take responsibility for ensuring that it's delivered successfully. If the architect has defined an architecture, why shouldn't they own that architecture throughout the rest of the project?

Leadership
Owning the bigger picture is one aspect of technical leadership, but there are other things that need to be done during the delivery phase of a project. These include taking responsibility, providing technical guidance, making technical decisions and having the authority to make those decisions. Somebody needs to undertake the technical leadership to ensure everything is taken care of and that the team is being steered in the right direction on a continuous basis. The software architect position is inherently about leadership and while this sounds obvious, many project teams don't get the technical leadership that they need. This is a natural part of the architect's role, but just mind that gap.

Coaching and mentoring


Coaching and mentoring is an overlooked activity on most software development projects, with many team members not getting the support that they need. While technical leadership is about steering the project as a whole, there are times when individuals need assistance. In addition to this, coaching and mentoring provides a way to enhance people's skills and to help them improve their own careers. Sometimes this assistance is of a technical nature, and sometimes it's more about the softer skills. Certainly from a technical perspective though, why shouldn't the architect help out with the coaching and mentoring? Most architects that I know have got to where they are because they have a great deal of experience in one or more technical areas. If this is the case, why shouldn't those architects share some of their vast experience and help others out.

Quality assurance
Even with the best architecture and leadership in the world, poor delivery can cause an otherwise successful project to fail. Quality assurance is a large part of an architect's role, but it's more than just doing code reviews. For example, you need a baseline to assure against, and this means the introduction of standards and working practices. From a software development perspective, these could include coding standards, design principles and source code analysis tools through to the use of continuous integration, automated unit testing and code coverage tools. It's safe to say that most projects don't do enough quality assurance, and therefore you need to figure out what's important and make sure that it's sufficiently assured. For me, the important parts of a project are anything that is architecturally significant, business critical, complex or highly visible. You just need to be pragmatic and realise that you can't necessarily assure everything.

Design, development and testing


The last thing that falls squarely within the role of a hands-on software architect is design, development and testing. Being a hands-on architect doesn't necessarily mean that you have to get involved in the day-to-day coding tasks, but it does mean that you're continuously engaged in the project, actively helping to shape and deliver it. Having said that, why shouldn't the day-today coding activities be a part of an architect's role? Most architects are experienced coders, so it makes sense to keep those skills up-to-date. In addition, the architect can experience the same pain as everybody else on the team, which in turn helps them better understand how their architecture is viewed from a development perspective. Many companies have policies that

prevent software architects from engaging in these coding activities because their architects are "too valuable to undertake that commodity work". Clearly this is the wrong attitude ... why let your architects put all that effort into defining the architecture if you're not going to let them contribute to its successful delivery? Of course, there are situations where it's not practical to get involved at the code level. For example, a large project generally means a bigger "bigger" picture to take care of and there may be times when you just don't have the time. But generally speaking, an architect that codes is a more effective and happier architect. You shouldn't necessarily rule out coding just because "you're an architect".
Tech lead
Technical Leads provide solutions to technical issues, and are responsible for meeting development schedules and ensuring the delivered solution meets the technical specifications and design requirements.

General Responsibility: Interface between team and management Write quality code, set an example of quality in front of the team members Gain the teams respect with the quality of your work and by doing what you are preaching Define early on what success means for you, the team and the business Set reasonable expectations in front of the team Should be part of the design team Should have design vision and understanding Be firm but fair Admit your mistakes Build and maintain high team morale Should not be biased towards any individual professionally but personally you can Task assignment should be fair Tasking should be done with the team together Match people and tasks based on their skills and their personal preference Work the estimate with the team Try to become a role model for the team Take necessary measures to avoid centralization of knowledge. There should not be any dependency in the project on anybody.

Mentor people; It is your job to raise the education level of your team Quality with on time delivery of agreed deliverable Team can approach lead any time for any functional or technical concern Tech lead requires balancing between technical and leadership talents. Lead should Motivate/encourage the team members Especially when team is under pressure with the tight deadline Lead should share the limelight with the team Dont blame anybody publicly for anything Work as hard or harder than anyone else in the team Focus on the technologies associated with the software or application you are building. Learn those technology thoroughly Flexible enough to work under different work environments settings Fun @ work At the end, always say WE instead of I

Team lead In todays ultra-competitive business environment, executives and managers often have varying degrees of leadership skills and training. While obtaining comprehensive leadership skills training is the best way to integrate key leadership responsibilities into the workplace, understanding and utilizing the following tips can help you resolve conflicts, improve employee performance and lead change throughout the organization:
Lead by Example This is one of the most important leadership skills. If you demonstrate a strong work ethic, your staff will follow. As an executive, you have a responsibility manage and guide the staff, to inspire enthusiasm and stimulate their interests. Make sure you look out for their welfare and they will be appreciative of your efforts by being productive and maintaining high company standards. Ensure Long-Term Organizational Success Focus on the long term. While there are numerous factors that could steer your company off-track the changing economy, the board of directors or technology in your industry you need to stay focused on the long-term success of your organization. Otherwise, there will be no roadmap or plan of attack. Improve the Organization from Day 1 From the day you start your position, its up to you to ensure that you grow your organization. Work on making your company more streamlined, fiscally sound and more respected than the day you walked in the door. Focus on the Big Picture Because boards prefer to operate at the micro level working on minor details and small projects, youll have to work at refocusing them on larger strategic issues with abstract or undefined results. This will take effort on your part, but if you dont push them to do it, nobody will be doing the boards job

Ask Tough Questions Part of your role as an executive is to ask the tough questions, even if it risks putting your job in jeopardy. Hard-hitting questions such as, Is this in the budget? or Is this ethical? can stir up controversy, but its better to ask than hold your silence and violate the trust to strengthen the company. Have a Basic Understanding of the Job and Organization Its simply not possible to know all the ins and outs of every position within t he company. Try to have a basic understanding of key roles within your organization, and make sure to keep informed of the growth and changes within your industry through local executive societies and publications. Be Committed Who cares? You do! By demonstrating commitment to your organization, your staff, your profession and your industry, others will be inspired to stay enthusiastic about their roles and contributions to the company. If you demonstrate any sort of negativity, others will soon follow. Maintain Integrity Much like leading by example, you always want to keep operations above board. Dont conduct any business in secret or that you wouldnt want the media to cover. Speak up about processes or issues that you know do not follow the companys ethical standards. While speaking up takes a great deal of courage, keeping silent can destroy your company and your career

Roles of a Project Team Leader

Leadership. The project leader works with the team and key stakeholders to set the key goals and major objectives. The PL is expected to maintain focus and provide clear direction to both team members and with respect to external influencers, to be the champion for the project, to be clear about the programs priority in the portfolio, to demand scientific excellence from team members and to support team member personal development. The PL will often be called upon to clarify the roles and responsibilities of team members both between potentially competing team members and to their bosses. A good leader actively solicits input from team members and key stake holders. The good PL also recognizes and acknowledges the contributions of team members. Decision Making/Judgement. The PL should include the team in formulating decisions but should accept accountability for the decision. Provide an honest assessment of the project relative to current and future cost. Proactively acknowledge the time to advance the project to the next stage (not weve got a couple experiments wed like to finish first) and when to recommend termination. Knowledge. Understand the scientific rationale and technical issues associated with the project target and lead agents (small molecule or biologic), with the clinical and market drivers, and with the processes and progression criteria associated the stage of Discovery or Development. Planning. The PL is responsible for developing a project plan that works to achieve progression criteria using sound scientific processes in the shortest amount of time with the least cost. The PL must challenge work that is not directly related to the critical path. The PL negotiates approval of the project plan with management. The PL ensures that the plan is re-evaluated, adjusted and re-negotiated at regular intervals, or when internal data or external information suggests that the timeline may slip or certain objectives may not be met. Influencing. Making sure all team members and their line managers and key stakeholders support the project. The term herding cats is appropriate.

Negotiation. The PL may need to interact directly with line managers to ensure resources are available when needed, and to negotiate amendments to the project plan especially those that change deliverable completion dates. Meeting Management. The PL is responsible for organizing, facilitating and ensuring follow-up action on issues raised in the meeting. When required, the PL will organize corporate scientific program review. Communication. Keep team members and stakeholders informed of key developments, program decisions, issues, and changes to the project and the project plan. Provide timely reporting in any corporate project reporting system or to any corporate review board. And promote and support external presentation of scientific advances made by the team. Provide relevant information to legal or regulatory groups as required. Alliance Management. Fulfill obligations to external alliance partners. Support to the project by the partner may be reported by way of an employee of the partnering organization who serves as an actual team member, or through regular communications managed by the corporate alliance management group. The extent to which functions of the team are outsourced, will determine the extent to which proper alliance management is critical to an adequately functioning project team.

Project manager Develop the project plan Manage and communicate with project stakeholders Manage the project team and project committees Manage the project risk Manage the project schedule Manage the project budget Manage the project conflicts Manage quality

Project Manager.(This is not a complete list)

* The Project Manager is the person responsible for managing the project.

* The Project Manager is the person responsible for accomplishing the project objectives within the constraints of the project. He is responsible for the outcome(success or failure) of the project.

* The Project Manager is involved with the planning, controlling and monitoring, and also managing and directing the assigned project resources to best meet project objectives.

* The Project Manager controls and monitors triple constraintsproject scope, time and cost(quality also)in managing competing project requirements.

* The Project Manager examines the organizational culture and determine whether project management is recognized as a valid role with accountability and authority for managing the project.

* The Project Manager collects metrics data(such as baseline, actual values for costs, schedule, work in progress, and work completed) & reports on project progress and other project specific information to stakeholders.

* The Project Manager is responsible for identifying, monitoring, and responding to risk.

* The Project Manager is responsible to the project stakeholders for delivering a projects objectives within scope, schedule, cost, and quality.

* The reporting structure of a Project Manager changes depends on organizational structure. He may reports to a Functional Manager or to a Program Manager.

In a bit exaggerating terms, Project Manager is the God of his project and he is the one who decides the success of the project.

Product manager
A product manager is sometimes called the CEO of a product, Define product strategy and roadmaps A product manager is responsible for defining the long term strategy of the product and express the details in a product roadmap. This roadmap and vision is what is considered as the plan of record for the engineering team to implement. Deliver MRD's and PRD's MRD's or market requirement documents include the voice of the customer, "markitecture" and is a component of the business case. The MRD is written by the product manager with assistance from research, marketing communications, sales, engineering and finance. The PRD or the product requirements document consists of the prioritized features of the product. Voice of the customer The product manager is responsible for tracking user feedback, customer satisfaction, dashboards and metrics to measure success and engagement of new and existing functionalities. Anybody in the product management role works with developers, ISV's, and evangelists to get feedback. Tactical responsibilities The product manager is responsible to maintain and manage technical partnerships, requirement analysis, prioritization, evaluation and negotiations of terms with engineering. External Partnerships Product Managers are typically required to work with external 3rd parties to assess partnerships and licensing opportunities.

Conduct competitive analysis Every product manager needs to be the guru when it comes to knowledge about competition. Product managers researches the competition's technology and gathers data around market share, direction of the industry and threat to the current product and business. Internal partnerships Product managers are required to closely work with cross functional teams such as engineering, sales, business development, evangelists and marketing to define, design and execute plans. A product manager is also required to make presentation to these teams and train them. Perform product demos to customers. The sales team often relies on product managers for good leads. At times its product managers who go in first to a customer to give a high level technical presentation and make a business case for the customer. A product manager is required to wear multiple hats, and to be successful in the product management role the product manager has to perform roles such as a project manager, visionary strategist, business owner, program manager, quality assurance, user experience police and sometimes even sales, business development and marketing.

More on product manager works in slides below

Program manager
This article considers five major aspects of program management:

Governance: Defining roles and responsibilities, and providing oversight Management: Planning and administering both projects and the overall program

Financial management: Implementation of specific fiscal practices and controls Infrastructure: The program office, technology, and other factors in the work environment supporting the program effort Planning: Activities that take place at multiple levels, with different goals. The program plan is not a traditional plan

Program governance
Program governance is the aspect of the discipline that creates both the structure and practices to guide the program and provide senior-level leadership, oversight, and control. Strategically, it encompasses the relationship between the oversight effort and the enterprise's overall business direction. It also encompasses all the decision-making roles and responsibilities involved in executing the program effort.

Projects are typically governed by a simple management structure. The project manager is responsible for day-to-day direction, a senior IT executive integrates technology with business interests, and a business sponsor is accountable for ensuring that the deliverables align with business strategy.

Programs require a more complex governing structure because they involve fundamental business change and expenditures with significant bottom-line impact. In fact, in some instances their outcomes determine whether the enterprise will survive as a viable commercial/governmental entity.

Responsibilities of a program manager/director



Accountable to executive sponsors for schedule, budget, and quality of all program elements. Leads high-level sessions for program plan and schedule development. Reviews/approves project plans for conformance to program strategy and program plan and schedule. Acts as the communications conduit to executive sponsors and program steering committee and conducts periodic briefings/status updates. Escalates decisions to executive sponsors as necessary

PMO roles

Program office management Resources coordination Budget administration and procurement Risk assessment Work products tracking and review Facilities administration Contracts administration Technical support liaison

Training coordination Methodology and process support Issues management Communications management Status reporting management

http://www.ibm.com/developerworks/rational/library/4751.html tech writer

Organize material and complete writing assignment according to set standards regarding order, clarity, conciseness, style, and terminology. 2) Maintain records and files of work and revisions. 3) Edit, standardize, or make changes to material prepared by other writers or establishment personnel. 4) Confer with customer representatives, vendors, plant executives, or publisher to establish technical specifications and to determine subject material to be developed for publication. 5) Review published materials and recommend revisions or changes in scope, format, content, and methods of reproduction and binding. 6) Select photographs, drawings, sketches, diagrams, and charts to illustrate material. 7) Study drawings, specifications, mockups, and product samples to integrate and delineate technology, operating procedure, and production sequence and detail. 8) Interview production and engineering personnel and read journals and other material to become familiar with product technologies and production methods. 9) Observe production, developmental, and experimental activities to determine operating procedure and detail. 10) Arrange for typing, duplication, and distribution of material. 11) Assist in laying out material for publication. 12) Analyze developments in specific field to determine need for revisions in previously published materials and development of new material. 13) Review manufacturer's and trade catalogs, drawings and other data relative to operation, maintenance, and service of equipment. 14) Draw sketches to illustrate specified materials or assembly sequence. Software engineer

Coordinate with the Technical Director on current programming tasks. -organized, optimized, and documented source code. d polish feature sets.

QA/QC

ESSENTIAL DUTIES AND RESPONSIBILITIES: The following duties and responsibilities have been determined to be essential to the successful performance of this position. - Develop and maintain the QA Plan and existing Manual. - Follow up QA Procedures implementation. - Communicate to respective team the QA System and monitor the implementation. - Identify non conformances and take preventive and corrective actions. - Lead non-conformance investigation with the relevant departments. - Promote to the team initiatives related to Quality - Assist in setting yearly Quality Objectives and Key Performance Indicators. - Assists as necessary the Engineering department in the evaluation and correction of specific quality control problems and issues. - Performs QA/QC Checks, audits and reviews - Manage the continuous Quality training, assessment and human factors of the staff - Maintain the Quality file system - Performs all other duties, tasks and initiatives contributing to the success of the company Again

To liaisew ith customersto resolveq ualityr elatedi ssues . To ensure the document and quality system is properly maintain o To train and assessQ A inspectorso n workmanships tandarda s and when required o To perform internal audit and quality system audit periodically o To conduct supplier plant audit as and when required o To act as a ManagementR epresentativ(eM R) of the Company o Ad-hocd utiesa s assignedb y ProductionM anager . To review and update procedures and specifications where applicable for the effective and efficient running of incoming inspection.

Vous aimerez peut-être aussi