I’ll be honest here, I don’t really curate my LinkedIn all that much, and I tend to accept any request to link. I do perform a little bit of filtering, but barriers to entry a low. Very low.
One thing I did notice that that, after my title change, I got a lot more requests from people I didn’t know (mainly recruitment consultants, so no surprises there). This got me to thinking:
What if I setup a fake profile with fake title (suitably impressive, like CEO), and just punted it out to LinkedIn. How long until the requests started pouring in?
OK, possibly too easy. Lets go one step further. Lets create a fake company with 26 profiles on LinkedIn. Each profile will be for nice, high ranking titles like CIO for APAC region, or CFO for EMEA. Each profile will also have a first name starting with a different letter of the alphabet. Now, here comes the fun. That fake profile will only accept requests from people who’s names also contain the starting letter of the profiles name (or, if this proves to be wildly successful, only accept requests from people who’s names start with the same letter as the fake profile). After 1 year, look at the network the fake company has built.
Sadly I’m far too lazy to do this (I suspect a fake company website may also be in order), but hey, this is the internet; there are people out there with WAY too much time on their hands. Take this idea, go, run with it. Report back in a year 😀
I’ve started using BDD scenarios for most things now as I find the Given/When/Then syntax great for focusing on the problem and generating questions. What I have found though is that often the questions need to be written down somewhere to ask the relevant person. Correlating the questions and the scenarios can be a pain so I’ve started putting them inline into my scenario text using a
?? notation. The format is simple:
?? on it’s own: denotes an outstanding question about the preceding text.
word??: denotes a question about the preceding word.
?option/option?: denotes uncertainty about which option should be used.
?question?: denotes a question being asked.
This syntax can actually be used to write the original scenario:
Then ?? should ??
An example of this usage might be:
Given a user on a web?? form
When the user ?enters/selects? ?should we be thinking about how the provides the data? their D.O.B.
Then the form should ??
A discussion, which could be via email or some other means than face to face, can than be had to resolve the questions using just the scenario files and the annotations to the scenarios. You could even go one step further and use something like Gollum to track the changes to the scenarios.
While lamenting the waste of a day waiting for a “7am-7pm” delivery which didn’t turn up, a friend of mine put the following on Facebook:
“The first delivery company to give a live schedule of how they reckon deliveries will pan out during the day, and keep it up-to-date, so you can at least see where you are in the queue… will make a fortune”
That got me to thinking, how hard would this be? Superficially I don’t think this is too hard a problem to solve using current technology. The hardest bit is the route planning and we can turn to Google for that. So what do we need for an MVP?
I’m thinking a driver app that contains an ordered list of postcodes, interspersed with any breaks the driver may have. The ability to reorder the drops and/or breaks. The ability to mark a drop as done. Here the definition of done is that delivery was attempted. Each time an update is made the app phones home with the current location and an ordered list of outstanding drops and breaks.
A server sits in the middle listening for these updates. Using the current location as the starting point the server will then traverse the drop off points querying Google to find out how long it will take to drive between each point. Store the time to each post code (including any breaks) with the post code.
A client page can then be used to query the server. It would find the correct ordered list of post codes, look up your post code and report how far down the list you are and how long, roughly, until the delivery will be with you.
Of course, the devil is in the detail, and integrating this with the drivers current handheld units, the parcel tracking software and everything else would take some thought, but the basic premis is there. If you were familiar with the Google APIs you could probably knock together a demo web page showing the drivers view at the top and the customers view at the bottom in a couple of days.