To the development team:
I want to congratulate you all on a job well done. K-M is a truly
remarkable achievement, especially when one considers that the development
seems to have occurred with only limited management.
I stumbled onto K-M while surfing a few days ago. After reading a bit, I
decided to download and try it out. I expected a primitive, immature,
incomplete and buggy alpha/beta product. What I found is a product superior
to both IE and Firefox (IMHO). (K-M is the best kept secret in WebWorld.)
That said, I suggest that the development team face the reality that K-M is
inevitably destined to become the most popular browser in WebWorld.
Tremendous pressures will arrive concurrently with this fame. The bottom
line is: you are not ready. No one is ever ready for the pressures of a
massive expansion. Scared? You all should be scared.
So, you have a choice. Quit the K-M project (e.g. hide from the coming
expansion), or prepare for the expansion (decide to ride the tiger and
become famous and probably rich).
An early step in preparing for the coming pressures is to bring the
beautiful, maturing monster that is K-M under development control. This
requires a formal, documented Statement of Objectives (SO), a requirements
document, to give direction to continuing development.
A System Specification (SS) and WBS (Work Breakdown Structure) to give
concise task level direction to technical development should elaborate the
SO. In addition, a clearly defined authoritative implementation management
structure is essential to success.
How to proceed may seem illusive so let me suggest some things:
1. To begin, the development team should designate (elect) a Lead
Developer (LD) and a deputy. (The primary mission of the deputy is to
perform the duties of the LD in his/her absence.).
2. The LD develops and maintains the SS and a derivative WBS (work
breakdown structure) of the tasks necessary to implement the various
elements of the design. Each element (WBS task) must be elaborated by an
SOW (Statement of Work) that clearly defines end product(s) of the task.
Task durations should be less than six weeks.
3. The LD assigns (allocates) WBS development tasks to other
developers, as he/she deems appropriate and according to the desires of the
individual developer.
4. The LD (and his/her assistants) will post unassigned WBS tasks in an
ad hoc forum. Developers desiring to participate in development will do so
by volunteering for tasks in the forum.
5. Developers will report their task progress weekly, or more often,
as deemed appropriate by the LD.
(Note: Thus, the LD forum will continuously reflect the status of the
development (broken down by WBS element task) for the information of
interested developers. Visit
http://www.projectconnections.com/jsp/regfinish.jsp
for software program management templates, requirements guides and examples
of WBS documents, flowcharts and schedules.)
The SOW's (Statement of Work documents) for each task also provide the
informational basis for the development of related user manuals and other
documentation.
M-K functional enhancements (new requirements) begin as additions to the SO.
The SS and WBS are an elaboration of the elements of the SO.
3. Enhancements (in the form of additions or modifications to the SO may be
recommended by any K-M registered user via the EF (Enhancements Forum (to be
established.)) and by editing the current SO-wiki and SS-wiki (to be
established).
The K-M Administrative Council (AC) is responsible for initially creating
the SO-wiki and SS-wiki, and for maintaining and freezing them periodically
(as design targets for the LD). The LD utilizes the current SS as the hard
target for development efforts.
K-M registered users elect the members of the AC (13 are suggested). The AC
members elect a Chairperson (and Vice Chairperson (VC), who acts as
Chairperson in the absence of the formal Chairperson). Typically, the VC
automatically relieves the Chairman when her term expires).
The AC utilizes the EF and SO-wiki and SS-wiki as source data for K-M
version design freezes. At freezes, the SO and SS (actually the WBS) become
the de facto current design targets and the basis for documentation detail.
The wikis become the baseline configuration point of departure for the
subsequent version.
The Chairman unilaterally determines the content and timing of K-M core
version and plug-in design freezes.
The Chairman appoints a QZ (Quality Assurance Czar) and a DZ (Documentation
Czar). (Czars train and appoint their deputies, who ultimately become their
replacements.)
Note: The QZ and DZ do not report to the LD. They report directly to the
Chairman. The QZ certifies (to the Chairman) the functionality of the
current M-K version at release (with exceptions). The DZ certifies (to the
Chairman) the accuracy and completeness of the current M-K documentation to
support the current M-K release (with exceptions). Only the QZ may
authorize the formal release of Beta or final M-K versions to the user
population.
The QZ and DZ do not rectify exceptions. They define them and report them
as tasks in WBS SOWs and post them in the development forum (EF) for
volunteers to undertake. The QZ and DZ will each maintain a blog or forum
to interact as necessary with volunteers addressing exception WBS task s.
|