Isso somente ocorre por aqui, em Florianópolis: Mulheres normalmente reclamam que os homens não prestam, e estes por sua vez, sempre dizem que elas querem demais... Interessante os pontos de vista discordantes desse conflito, onde mulheres esperam muito dos homens, que por sua vez, por não terem o real conhecimento
do quê elas esperam, acabam passando a imagem de desleixados, relapsos, insensíveis ou inadequados. Seria isto uma realidade? Somos assim tão a quem das expectativas?
É realmente complexo assumir a postura: "Eu sei tudo o que você precisa, não se preocupe, vou satisfazê-la!" e não quebrar a cara dentro de uma relação. Isto porque é humanamente impossível saber de antemão o que pode ou não satisfazer uma mulher sem que ela mesma seja consultada a respeito. E todos nós somos diferentes neste sentido... é necessário que a conquista seja iterativa, isto é, a cada momento descobre-se o que é necessário fazer para suprir uma necessidade, obtém-se o feedack e parte-se para outra necessidade... hehehehe simples né?
Seria nossa atitude como profissionais semelhante? Não estaríamos tentando satisfazer clientes imaginando de antemão tudo que ele possa querer?
Motivação para mim é um assunto bastante delicado, e está solidamente aplicado em conceito do Desenvolvimento Ágil, talvez as características psicológicas e sociais relacionadas ao Scrum e XP é que tornem sua utilização mais agradável para as equipes.
Ciclo de expectativa e a atuação do ClienteComo consumidores que somos, no dia-a-dia, sempre temos uma opinião formada sobre o que nos agrada e o que não nos agrada. O fato desta noção ser tão pessoal, faz com que muitas vezes tenhamos uma postura pessimista com relação a alguns produtos, já que não existe uma preocupação em produzir algo personalizado, que atenda nossas próprias necessidades.
O modelo de
entrega contínua de valor agregado e feedback contínuo em práticas de
Sprint Review,
Sprint Planning,
Jogo do Planejamento,
Cliente Presente e
iterações menores garante maior
satisfação do cliente.
Infelizmente, expectativas são inversamente proporcionais à satisfação. Isto é, lembrando do exemplo amoroso acima, quanto mais uma mulher espera de um homem, menor será a satisfação que ela terá ao perceber que não é possível para seus parceiros suprirem tais expectativas.
O mesmo ocorre com seus clientes, que esperam 6 meses ou até mesmo um ano para poderem visualizar o software em funcionamento. Assim, o resultado esperado por eles não consegue ser atingido, já que eles passaram tempo demais fantasiando como seria o sistema.
No
Desenvolvimento Ágil trazemos para nível contornáveis esta balança entre expectativa e satisfação. Isto é: se quanto mais se espera de um sistema maior é a frustração em não obter o resultado, vamos diminuir a quantidade expectativas e, no menor tempo possível, receber o feedback necessário para mudar e adequar-se às novas expectativas que surgem.
Simples? Nem tanto. As várias práticas relacionadas acima se unem para garantir que o cliente esteja sempre satisfeito, ou ainda, que no menor tempo possível ele receberá algo concreto com o qual poderá gerar valor para sua empresa.
Scott Ambler traz de forma exepcional uma comparação entre modelos tradicionais de feedback e os modelos Ágeis, que trascrevi uma parte neste post (sim, em inglês). Leia o
documento completo| Technique | Description | Feedback Period |
| Active Stakeholder Participation | Stakeholders (users, managers, support people, ...) are actively involved with the modeling effort, using inclusive techniques to model storm on a just in time (JIT) basis. | Hours. A stakeholder will describe their requirement(s), then the developer spend several hours, or perhaps day or two, implementing them to produce working software which they can then show to the stakeholder(s). |
| Agile Model Driven Development (AMDD) | AMDD is the agile version of Model Driven Development (MDD). With an AMDD approach, at the start of a project you do some high-level, initial requirements modeling and initial architecture modeling. During development you model storm on a just in time basis. | Hours. With model storming, you explore a requirement with your stakeholder(s) or a technical issue with other developers and then spend several hours or days implementing working software. |
| Big Design Up Front (BDUF) | With a BDUF approach, a comprehensive design document is developed early in the project lifecycle which is used to guide the implementation efforts. | Months. It is typically months, and sometimes years, before stakeholders are shown working software which implements the design. |
| Big Requirements Up Front (BRUF) | With a BRUF approach, a comprehensive requirements document is developed early in the project lifecycle which is used to guide the design and implementation efforts. | Months. It is typically months, if not years, before stakeholders are shown working software which implements their requirements. |
| Code Inspections | A developer's code is inspected by her peers to look for style issues, correctness, ... | Days to Weeks. Many teams will schedule reviews every Friday afternoon where one person's code is inspected, rotating throughout the team. It may be weeks, or even months, until someone looks at the code that you've written today. |
| Continuous Integration | The system is built/compiled/integrated on a regular basis, at least several times a day, and ideally whenever updated source code is checked into version control. Immediately after the system is built, which is often done in a separate "project integration sandbox" it is automatically tested. | Minutes. You make a change to your code, recompile, and see if it works. |
| Model With Others | The modeling version of pair programming, you work with at least one other person when you're modeling something. | Seconds. You're discussing the model as you're creating it, and people can instantly see a change to the model made by someone else. |
| Model/Documentation Reviews | A model, document, or other work product is reviewed by your peers. | Days to Weeks. A work product will be created, the review must be organized, materials distributed, ... The implication is that it can be weeks, or even months, before the item is reviewed. |
| Pair Programming | Two developers work together at a single workstation to implement code. | Seconds. You're working together to develop the code, the second coder is watching exactly what the person with the keyboard is doing and can act on it immediately. |
| Test Driven Design (TDD) | With TDD, you iteratively write a single test then you write sufficient production code to fullfill that test. | Minutes. By implementing in small steps like this, you quickly see whether your production code fulfills the new test. |
| Traditional Acceptance and System Testing | Acceptance testing attempts to address the issue "does the system do what the stakeholders have specified". System testing, including functional, load/stress, and integration testing, attempts to address the issue "does the system work". With traditional testing the majority of testing occurs during the testing phase late in the lifecycle. Testers will write test cases, based on the requirements, in parallel with implementation. | Months. By waiting until the system is "ready for testing", the testers won't see the system until months after the requirements are finalized. |
Entre amores e projetos, seguimos tentando a todo custo gerar um único valor: satisfação.
[]s
