Perhaps the most important workflow any of us encounter is the one least talked about: That is, the flow of, well, our work. Not of our content through a CMS, but of the process of building that CMS in the first place. Or, for that matter, any web project.
>> Hướng dẫn Integrating multisite Drupal với Apache Solr
>> Giới thiệu the future of decoupled Drupal
>> Lịch sử module Drupal Statistics, thống kê truy cập
Many electrons have been spilled extolling the merits of Agile development and the evils of Waterfall development, the two popular workflow archetypes. The real world, as ever, is not that simple. Especially when we speak of consulting projects rather than in-house teams, pure Agile is rarely acceptable; it lacks long-term predictability (by design). And good design (both visual and technical) requires some level of up-front gestalt planning.
Every project is different, but what does an ideal project workflow look like? And how can we try to approach that ideal more readily?
There is an old British military adage: Proper Prior Planning Prevents Piss Poor Performance.
Up-front planning of a project is crucially important, especially when some stakeholder asks the all important question: “So will we be able to do it within budget and/or timeline?”
Good planning is how you are able to answer that question.
More important, though, that planning phase (often called “discovery”) is where the architecture of the project is defined. That architecture encompasses three different, closely-related areas: Content Strategy, Design, and Architecture.
Content strategy is one of those fields that has only recently received a name, but has been around as long as good websites have existed. It can be thought of as the “architecture of information” (not to be confused with information architecture, which is a subset of content strategy), or perhaps design of information. Content strategy is concerned with questions such as:
For our purposes, one of the most important parts of content strategy is content modeling; that is, designing an abstract skeleton of the content, abstracted away from any particular presentation, in a sort of platonic form. (For more on platonic content, see my blog post.)
By design, we're talking specifically about visual design and user experience: The look and feel of a site, the user-flows through the site, the mood and tone the site should have, and so forth.
But that user interaction depends heavily on what the content actually is. What content is the user interacting with? What are the design components we need, and how do those relate to the content model? Are they aligned with each other, or at odds? If we don't know that, then we're designing in a vacuum, and that almost never ends well.
Even the most brilliant content strategy needs a technical system that can house, maintain, and sustain it:architecture.
Not all CMSs are created equal. That's not a snark on any particular platform. Every CMS, Drupal included, has its strengths and weaknesses, and those will impact both the design and the content strategy. Just like planning a painting requires knowing whether you're working with acrylic or watercolors, a successful content strategy and design needs to know what its medium will be. A design that has no viable editorial process to back it up, for instance, will grow stale very quickly.
In the discovery phase, all three of these lines of work (content strategy, design, architecture) need to happen in concert. They cannot proceed waterfall-like from one to the next, because each one reinforces the others. The architecture may make certain seemingly difficult design concepts surprisingly easy (or vice versa), and certain design needs may necessitate certain content strategy decisions. And someone on the team (really, everyone) needs to consider, at all times, the editorial experience – that is the most easily forgotten part of planning, but the worst part to leave to the last minute.
The most important questions to ask during discovery are “What is this for?” and “How is it updated?”
From a workflow perspective, the content strategist, designer, and architect all need to be collaborating. (Sometimes one person can fill two of those roles, but very rarely three.) The tools they use can vary. User stories and acceptance criteria are common tools, but they are just tools and should not be considered sacred parts of the workflow: the sacred part is collaboration – a give-and-take effort between all three disciplines.
Often when that three-part conversation doesn't happen, it's for business reasons. A design firm is hired first, then, when they're done, a development firm is brought on board. Or, in the case of an application rather than a web site, sometimes the other way around. Neither is good, because it robs both of the necessary feedback.
It's easiest if all three parties work for the same company, but as long as they are in regular communication, that's not a requirement. What is a requirement is that none of them has veto over the others.
One of the most important parts of a project is when the implementation and design are compared, and the team can push back and say, “This thing here is going to be vastly more complex than it looks in the mockup,” or “You know, we could do this other thing easily; would that enhance the content plan and design?”
The earlier that interaction happens, the better.
A design made with no regard for implementation complexity or content model will cease to be cool as soon as it leaves Photoshop; a content strategy that ignores the modeling capabilities of the CMS will be non-implementable; and an architecture that goes for the easy cookie-cutter will result in a site that is, well, cookie-cutter.
The output of discovery is a plan for how to implement all three aspects of the project: How it will be built, how it will be styled, and what tools will be used. Of course, that brings us to a German military adage: No plan survives contact with the enemy.
No matter how carefully the plan was laid, it will inevitably change before the project is done. There are two key reasons for that: first, the project requirements change, due to changing business circumstances, some senior executives deciding to leave their mark, or simply some need or nuance that was forgotten and not caught during planning; second, expectations involving the level of effort required to actually carry out the plan could have been off, and some feature may require substantially more work than anticipated (or, rarely but pleasantly, much less).
Make no mistake: those snags will happen on nearly any project. It's not a question of if, but when. For that reason, a good project workflow has no such concept as “final sign-off.” No part of the content strategy, design, or architecture can be treated as irrevocably locked. However, it should only be “unlocked” by the project team. They are the ones that are "in the trenches" (to continue the military theme), and therefore they are the ones who have the best sense for when a given decision needs to be revisited.
When the plan needs to be adjusted, all three elements – content strategy, design, and architecture – need to be accounted for. If they were developed in tandem, then any change that is logical for one is likely to be logical for the others but not always. So ideally, the content strategist, the designer, and the architect will be available throughout the project to guide adjustments as needed.
Often, that is cost prohibitive however. If only one element can be kept throughout the duration of the project, I would argue that the architect is best suited to work solo. This is the implementation phase; the technology is the part most likely to necessitate unexpected changes. Even then, the architect should be at least semi-fluent in content strategy and design, or have someone on the team who is.
While the focus of discovery is on collaborative planning, the focus of the production phase is incremental enhancement. That brings us to the topic of iterations.
Agile loves its iterations, but often has an expectation that every iteration includes a shippable product. In practice, that is counter-productive on a consulting project rather than a startup with a single application that is going to pivot every month. The goal of tackling one complete piece of functionality at a time, in order to have a small number of finished features rather than a large number of half-finished features, is laudable. But don’t allow that goal to result in wasted work.
This is an area where an in-house project and a consulting project differ greatly. With an in-house project, the end goal is generally more amorphous and subject to change. With a consulting project, the consultant was hired to solve a particular problem and that problem should remain relatively stable over the course of the engagement.
If the project requirements are rapidly and indefinitely changing, and the production team is expected to adjust without pushback, then it's not a consulting arrangement but rent-a-coder. There's nothing necessarily wrong with that arrangement, but the two are not the same.
For example, we said we should have a plan for the complete content model before production begins. In Drupal-speak, that means the content types, views, taxonomies, and so forth are known up-front and often will depend on each other. In practice, it is generally far more efficient to build out all content types and taxonomies at once, (especially in Drupal 7 where they have to be Feature-ized) than to spread it out piecemeal over several iterations. If you've done it properly, then you already know every field name, because they will sometimes be shared between content types. So just build them all at once and save time.
In my experience, while the content model will shift a bit during production, it rarely changes radically unless the planning was faulty or the business needs change radically. More often than not, the build spec we start with is 95% the same as the one we end with. Some content types or view modes may not get themed until much later, but it doesn’t harm anything to have them built out.
Various steps will also have dependencies. User stories, ideally, do not have dependencies on each other. However, I have yet to see a project where that was universally the case. Certain features or design components only make sense in the context of some other feature or design component. While that should ideally be minimized, it cannot be eliminated. That will also dictate what work happens in what iteration.
In a consulting workflow, each iteration is valuable not so much for the ability to pivot and reprioritize but as a way to have frequent “stability checkpoints.” Each iteration should be its own QA testing. A large QA period at the end of the project is an indication that there was insufficient QA earlier, which is a bad workflow: it encourages the accumulation of technical debt (or design debt, as the case may be).
Instead, a rapid turnaround time for the team to validate its work is crucial. If problems are found that cannot be fixed within the same iteration, they should be prioritized for the next iteration. Bugs before features. While hard for some product owners to swallow, prioritizing features over bugs only encourages bugs to breed. Technical debt piles up, errors increase, and the last few iterations need to abandon feature development entirely just to fix everything that was left over from before.
If the number of issues found at the end of an iteration is higher than desired, don't ignore them for the sake of feature velocity. Stop, fix them immediately, and improve the in-iteration QA process for future iterations. A good feedback loop addresses the root of a problem as soon as possible, rather than leaving it for later.
Another part of validation is deployment. Every iteration should end with the latest code running on a production or production-equivalent environment. Not doing so is the same as having a design flaw or code bug that is left unaddressed. The longer it is left to fester, the worse it gets.
No two projects are the same, yet the processes by which they are addressed should be. The underlying principles for a successful consulting project workflow are fairly consistent:
And that's a successful workflow plan.
Drupal Developer having 9+ year experience, implementation and having strong knowledge of technical specifications, workflow development. Ability to perform effectively and efficiently in team and individually. Always enthusiastic and interseted to study new technologies
Many more people all over the world are becoming cautious about the food they eat. If you are one of those who are very keen on their diet or weight then this is the app for you.
Chuyện gì xảy ra khi Chợ Điện Tử, một ông trùm thương mại điện tử, dùng tiền để nhanh chóng khẳng định sức mạnh của mình trên các máy tìm kiếm với các thủ thuật seo mũ đen. Liệu họ có thành công với phương pháp của mình?
This tutorial was requested by a student who is learning the Drupal basics. They turned on "Clean URLs" in the Drupal admin area and were surprised to see that the URLs remained largely unchanged:
Bình luận (0)
Add Comment