Ask HN: What should I include in a tech discovery phase? | Hacker News Reader

Ask HN: What should I include in a tech discovery phase?

11 pointsmattew4 comments

We just got a new lead, and they want to buy a "tech discovery" phase from our software development consultancy. They basically have an idea, a graphic designer, and an information architect. They will put together a set of wireframes and we will be responsible for figuring out what they need on the technology side. I want to be able to come out of this phase with the ability to make a phase 1 development proposal for the first working prototype. They have enough budget for about 40 to 50 hours of work in this phase.

What do you normally include in the proposal at this stage in the game?

View on HN

I guess if I had five days to produce a "tech discovery" document like you describe for a non-technical audience, it would be breaking down the tasks and providing detailed estimates. Software estimation is very hard; I'm no good at it, but when I've been close to the mark, it's been because I broke down the tasks into 1- or 2-day chunks.

If I were to work on it, I would start by reading their wireframes and building a mental model -- at a high level, how the app must work. Then, if applicable, I would search for libraries which will save lots of time; the presence of an important library may pull me strongly towards certain languages, platforms, or architectures.

Once I had decided on platform and architecture (not in stone), I would start writing out the details of the tech into a document. I would put in all the technical stuff I thought I might need at first, because it's more for me to build my model right now than to give to the client. I'd spend two or three days on this, focusing on identifying the risks. If the risk is huge or easy to research, I would research it at this time and see how to mitigate it. I would also not be shy about calling them up if I think I might have a misunderstanding, as a few minutes on the phone might save hours or days.

Anyway, the last step is to distill the document for the audience. At this point I should have all the information to produce a document that includes an estimate, risk analysis and implementation plan.

[Edit: I probably sound obnoxious by using "I would" everywhere rather than "you should". (Sorry!) But I have no actual experience doing this sort of thing, so I feel dishonest giving prescriptive advice.]

I've been in this kind of situation, but with less expertise on the client's side.

My (successful) angle of attack was to review the documentation provided as a kind of "requirements dump" rather than a "this is how it should work" definition. I then applied my own knowledge and experience to generate a document that said "these are the features you asked for, here's how to provide them in a user-centric manner."

As your client apparently has the IA and graphics person on their side, you may be more constrained. I'd still put forward some ideas, in a conversational manner. Two reasons for this. First, maybe I have a better idea than them. Second, it shows that I'm more than a code monkey (or a bunch of code monkeys calling itself a consultancy).

The work product should include some idea of how you're going to attack the problem, and a sense of how long it'll take (fixed bids are for the devil), and prioritization based on client requirements and prerequisites that those requirements may have.

Thanks, Paul. This was helpful in my thinking on this.

I should add that the client here is a non technical person. He basically has a decent idea, and some money to get it going.

Reply on news.ycombinator.com