Ask HN: how can I brief my devs better as non-tech founder?

[rafweverbergh]

I'm a non tech founder working with outside developers (at least until product market fit).

I'm mostly doing fine with briefings, but occasionally the developers misunderstand how certain roles and permissions interact.

I found an article about "Actor-Role Patterns", which seems like interesting stuff but which is also too advanced for me to create briefings based on it.

Ideally, I would provide my developers with a very clear diagram of what the entire application is supposed to do. The problem is: I have no idea where to begin looking.

You would help me tremendously by throwing me some breadcrumbs. Thank you in advance!

[RollAHardSix]

You need to pick up pen and paper and create diagrams and flowcharts, if you can't chart it out, it probably doesn't make any sense. If you get confused, grab your senior developer and explain to him one on one what you are trying to achieve. It doesn't matter that you are a non-tech founder, your working with developers, you need to adapt your processes to how developers think and work.

Bullet-points work great and provide easy references to things like intended file-names, and also provide an easy way to break down a conditional statement.

You need to look into psuedo-code, because in a way, that's what you're looking to provide. Otherwise, you might as well just give the developers and the client a one on one and get out of the way. You have to be providing something that makes the developers life easier then handling all the interaction themselves and that something provided has to be something other than just time.

We need to understand the purpose of the system, how it works into the overall program, how it should look, how it should feel, intended program flow, intended results, we need to know a lot of everything not a little of everything.

You also need to be almost constantly available to answer a quick question. There are just too many issues that may crop up while working on a program, case in point I was working on a project earlier today which featured two different types of an overall master type inside a record of a database. I made a (highly educated) assumption of which type I was using based on context but I could have been wrong. Knowing which sub-type to use was something that wasn't available to me immediately with the information I had on hand and didn't appear to be an issue during our requirements meeting, it only popped up when I was re-checking program flow, specifically error catching. These little things can happen all the time, and the only real way to beat them is communication.

[rafweverbergh]

Thanks for this input.

[sharemywin]

Not real familiar with the term briefing? but if you mean like a requirements meeting. uses cases are pretty useful:

http://en.wikipedia.org/wiki/Use_case

There's also interaction diagrams and state diagrams depending on the type of software your using.

[rafweverbergh]

A "briefing" is a term from advertising & PR agencies. It is a document in which the customer explains what their business context, goals and "value demand" is, at what budget etc etc.

Thanks for the link, I will look into it. I worked with use cases and user stories, but user stories will frequently have some gaps in them - and it's in those gaps that misunderstandings occur. I was hoping that there's a universal language to create bullet proof models.

[georgemcbay]

"create bullet proof models"

Assuming that is possible (for anything but the most simplistic of systems) is likely the root of your problem.

[rafweverbergh]

I thought this might be ambitious, yes. Although at this time the system is (still) really quite simple.

Also, I thought: there must be a better way than saying: "So when user A logs in and merges records X and Y, user B will see the changes but not user C because he's not an admin".

But apparently I am mistaken?

[RollAHardSix]

I'd wager you just aren't being clear enough. From what you just said, I have zero context as to why user B can see those changes. I can make a guess, because he's an admin, but it's just that, a guess based on the little context you provided about user C not being an admin and being unable to see the changes.