

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

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.<p>What do you normally include in the proposal at this stage in the game?
======
lincolnq
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.]

------
paulhart
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.

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

------
mattew
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.

