all data is live and searchable
|
Basic Assignments
|
Options & Settings
|
Main Time Information
|
||||||||||||||||||||||||||||
|
|
|
Yellow
|
|
|
Sorry, no photos available for this element of time.
|
|
|
|
Notes:
|
|
On a GoToMeeting session with Steve, Alan, and Eric. We fixed a small filter on a custom homepage that deals with quotes and sub queues. We then went into more of the processes and procedure stuff. Eric helped Alan and I with some of his background and experiences. Good to hear some of that stuff. It really helps Alan and I capture some of the gems and highlights from Eric's experiences. From Eric - "Developing without project management is like a runaway train." Well said. Eric loves small frequent deliveries. Depending on the project, you may have to go deep before being able to give a deliverable. Other projects, you can push things out quicker. Think about the low hanging fruit. What is good and will give the most value without taking forever. You also have to consider dependencies and not orphaning things off on their own. - Don't customize things if you can find a way to standardize things. Think bigger picture. Make sure that a custom job is really a needed custom job. - The adilas team is somewhat of an unstructured group of developers and project managers. We may need to mix and blend based on the client and the project. Most of our projects are small to medium. If we play in the bigger field, we do need more of a real process. That could be a minimum requirements document and a design mock-up. - Sometimes showing some small prototyping can really help the discussions and talks move forward. People love to play with things. They also tend to be more understanding if they see it being built. That is awesome. - With adilas, we are small and it is really hard to implement full on teams and processes and procedures. We have to somewhat fake it and pull things together as it comes. We are growing and building, but we are still somewhat smallish in the team side of things. - Eric has been really good at taking the "one-off" development and trying to circle it back around and make it part of the core. That is awesome. We need to keep grabbing the ideas and information and then help build out the processes. Whether it is pricing engines, loyalty points, etc. Maybe we should try to work more together as small teams and small groups. We could really gain some advantages there. - Sometimes the developers don't know the whole system. They need some help in knowing the underlying design, concepts, and reach of the project. We need to help the developers know the architecture. Maybe even have the developers tell us what they understand. We need to check for understanding and make sure that they get it and can see the vision. We virtually don't send anybody into the forest without a guide of some kind. - Limit the number of projects at a single time. The more projects you have on your plate, the more you get spread out and lose some time in the transitions. The more you can focus, the better. - Sometimes growth comes with pain... Eventually it comes back to the 4 main stages of team development. They are forming, storming, norming, and performing. Things tend to go in cycles. If things get too far out, you end up having to do tons and tons of maintenance. - Eric was saying that he would love to have some well written documents but there is a trust level and a level of comfort on who is providing the specs. Eric really loves to be involved with the actual customer. It helps you get a flavor or what is needed and what they want. - Many of our developers are virtually a one-point shop. There are some huge advantages on that kind of person. Speed to get a project done can really increase. At the same time, some smaller teams, as needed, may really help us push things through faster and faster. - What are the benefits between small groups or being a smaller one-stop-shop type developer. Eric has done a great job of checking in and making sure it was ok in the direction he was going. Truly being a isolated one-man-show isn't good for anybody. We still need to check in and get some communication going on. Often we have other projects that are circling around and could help with your current projects. - If you are in a small team, there is some potential better communications. However, the bigger the team, the harder the communications could be. If you are building in a team, it helps to not create things that are going to be left out and/or standing alone. Teams work really well if you can mix and blend the talents of the team. It is also good if more output is needed. The bigger the team, the bigger the cost, the bigger the management that is needed. - Eric really likes to be able to talk with the end users. That helps him get more into the project. If we have a number of smaller more nimble dev teams (single developers or small teams of 2-5), that would be awesome. There are tons of different personalities, we may need to cater to some of those different people and where they feel comfortable (virtual roles). - What benefits can each person bring to the table? We may want to keep things open and allow people to help play where they want to play and where they have skills. - Eric has seen huge benefits from running things through a fuller project management style. Eric also thought that having a project architect on was huge. That was the person who helped make sure that things were flowing and going in the right direction. |