3 ms·

> I want my customers to understand what they are paying for and what I am committing to That's what I'd like to see from everyone (generally spoken). Anyhow,

by NaTopp 4y ago

> I want my customers to understand what they are paying for and what I am committing to That's what I'd like to see from everyone (generally spoken). Anyhow, thanks for your thoughts and sharing your experiences! There is a lot of value in it. I guess communication is - as usual - a huge factor in all of this (from each party). ---- > For example I commit to my customers that I will answer routine emails the same day, and urgent emails or phone calls immediately. That's very valuable and honest from you. But it's you who is doing that. Not everyone acts like that (from my experience). So how would one be able to create a proper adherence for such a commitment (that was agreed on while signing the contract)?

gregjor 4y ago
I don’t know how your company works, so I’ll make general comments. People who manage, including those who manage programmers, too often don’t actually do the work of managing. A big part of managing a team or project is making sure everyone knows what they are expected to do, how long that will take, how much it will cost, what risks it involves. It also means discussing alternatives and fallbacks. At all times the manager should know what people are working on, when to expect delivery, and know how to detect schedule/cost slips early on. The programmer(s) should know exactly what they are supposed to be doing, and what “done” looks like — what their deliverable is. What I actually see most of the time is vague requirements like “make an e-commerce site in six months” from management (or in my case, customers), and the programmers left on their own to figure that out. Then the team spends five months arguing about programming languages and tools and the “best” approach to edge cases while nothing gets delivered, and their manager is not paying attention. If the manager set the deliverables the team could work to deliver in a clear way. “Site structure with navigation but no content or functionality in two weeks,” for example. Give the team a few days to decide on language and tools and so on then move forward. With short iterations it should be obvious fairly early if the tasks are too vague, or the estimates are way off, or if the team is not working on the agreed-to goals. When those problems become apparent the manager (or customer) and the programming team identify the cause and adjust so the next iteration (call it a sprint if you want, same thing) goes better. The team should be delivering all the time — manager should not allow 80% of the schedule to go by without seeing continuous progress. In my case I’m putting something in front of my customers every few days, and my deliverables are easy-to-measure things like (for example) import these CSV files into a Postgres cloud instance, or verify that the addresses users enter have valid ZIP codes. With a more experienced and “gelled” team you can make the deliverables a little broader. I’m describing Agile development, but not the rituals and nonsense that have made the term almost meaningless. Iterative development with clear tasks and deliverables, and a feedback loop with the customer, right from the beginning. As for communication, you can set those expectations and if the programmer is not talking to the team, or the manager, or customer, within the time limits you both agreed to, you have a performance issue to deal with. Poor communication sinks projects more often than not understanding binary trees. From my own customers the number one thing I hear is “The last developers stopped answering my emails and phone calls.” I make a point to always answer and keep my customers informed, which puts me in the top tier of freelancers even if I’m not the most technically awesome programmer.

by NaTopp 4y ago

gregjor 4y ago

I don’t know how your company works, so I’ll make general comments. People who manage, including those who manage programmers, too often don’t actually do the work of managing. A big part of managing a team or project is making sure everyone knows what they are expected to do, how long that will take, how much it will cost, what risks it involves. It also means discussing alternatives and fallbacks. At all times the manager should know what people are working on, when to expect delivery, and know how to detect schedule/cost slips early on. The programmer(s) should know exactly what they are supposed to be doing, and what “done” looks like — what their deliverable is. What I actually see most of the time is vague requirements like “make an e-commerce site in six months” from management (or in my case, customers), and the programmers left on their own to figure that out. Then the team spends five months arguing about programming languages and tools and the “best” approach to edge cases while nothing gets delivered, and their manager is not paying attention. If the manager set the deliverables the team could work to deliver in a clear way. “Site structure with navigation but no content or functionality in two weeks,” for example. Give the team a few days to decide on language and tools and so on then move forward. With short iterations it should be obvious fairly early if the tasks are too vague, or the estimates are way off, or if the team is not working on the agreed-to goals. When those problems become apparent the manager (or customer) and the programming team identify the cause and adjust so the next iteration (call it a sprint if you want, same thing) goes better. The team should be delivering all the time — manager should not allow 80% of the schedule to go by without seeing continuous progress. In my case I’m putting something in front of my customers every few days, and my deliverables are easy-to-measure things like (for example) import these CSV files into a Postgres cloud instance, or verify that the addresses users enter have valid ZIP codes. With a more experienced and “gelled” team you can make the deliverables a little broader. I’m describing Agile development, but not the rituals and nonsense that have made the term almost meaningless. Iterative development with clear tasks and deliverables, and a feedback loop with the customer, right from the beginning. As for communication, you can set those expectations and if the programmer is not talking to the team, or the manager, or customer, within the time limits you both agreed to, you have a performance issue to deal with. Poor communication sinks projects more often than not understanding binary trees. From my own customers the number one thing I hear is “The last developers stopped answering my emails and phone calls.” I make a point to always answer and keep my customers informed, which puts me in the top tier of freelancers even if I’m not the most technically awesome programmer.