Sounds like a great project in that: - the customer is not just on the room, he's hacking on the code - you're got an existing tool and system in place - much easier than starting from scratch - it's an internal project - users can be exposed to it before it's polished - you have an existing userbase - tight feedback loop
Im guessing you'll be able to make decisions on what features do and don't get done. DHH looked back on Basecamp and said it wasn't actually Rails that made him so effective, it was having autonomy in making design decisions. You can get a lot more flow from a project you're close to. Best of luck with it! :-) - Mike On Tue, Feb 1, 2011 at 9:34 PM, Tim McEwan <[email protected]> wrote: > Hi all, > > Thanks for the thoughts and assistance - much appreciated. > > @Clifford: we aren't using MS Project and ~35 of our 60+ staff and students > are Mac users - so it gets really cumbersome when you're tied to a PC-based > solution. (We're coming from Filemaker + Excel. Filemaker was chosen b/c > it was cross-platform, but then they tied it to Excel via ODBC on PC, which > they could never successfully replicate on Mac.) > > @Nicholas: you're right, there's still some behaviours that are ambiguous > so I need to story it all up. Also, this is meant to be a replacement > component for an in-house project management system that's been live for > over a year now, so we have production, staging & CI servers already setup. > Design expert? Ha! The push is for functionality right now. :-) > > @Ben: that's interesting - I haven't studied SE or even CS (I have a nano > degree!) so I'm kind of winging it. Early on in the user-consultation phase > I asked people to try and forget about everything and tell me how they plan, > etc. But we've got an established history and systems that people are > familiar with - from here and other places. When it comes down to it, we > have to allocate people to tasks and time to people - while dodging leave, > their > work on other projects, varying availabilities, etc. - over a large time > span (making calendar formats a little too unwieldy), there's only so many > ways to do that, right? In the end it became easier to ask them what they'd > change about the current system. > > @Jason: being the in-house sysadmin, I get feedback from my colleagues > every day - if it's not up to snuff, they will let me know (loudly and > frequently). > > @Daniel: I'm after a guru coder to work closely with so that I can learn > from them. As I'm a permanent employee of the institute, training me up > adds value. > And there's no way a training manual would cut it - it's not that the > current system is complicated, it's that it lacks functionality. We have > some staff going to back to Excel to plan and having a casual copy the > numbers into the web interface. :-( > > > Thanks again all! > > -- > Tim McEwan > > <snip> > > -- > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<rails-oceania%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/rails-oceania?hl=en. > -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
