Surviving at the Software Industry. (4)

Today I'm gonna try something different. When I write about something I usually have all the resources on hand. But I feel my two last blog entries have been pretty stiff, so today I'm going to do it just by remembering the chapter, so if I'm missing something important, please tell me in the comments below!

I found this guide is just that. A guide. I'm learning as if a friend was telling me how to do something and not as a regular book, and that's just lovely. Now I know what book would I take with me if I was on a desert island. (Guide on building boats.)

 

So this chapter talks about those skills we should have if we are planning on starting a project.

• Checkpoint Overview: Having mock-ups and UX prototypes, and stuff like really well detailed software requirements is super important when you are about to take a decision on doing a project or not.
• Risk Management: Being prepared for everything, even the worst-most-impossible scenario out of all. Failure in some cases could mean the team not eating for a while, and man, humans literally can't work that way.
• Project Control: Everyone is doing it's part and CAN manage it. As a project manager you are responsible for the life of your project, as well as the well-being of everyone on your team.
• Project visibility: Have you ever felt that you "kind of" achieve something while coding? Visibility helps you to understand what have you actually done and what you haven't. It is important for a PM to know in what ACTUAL stage the project is at any time.
• Peopleware: Rule #89 of being a programmer: Never forget that normal people don't know how to code. Knowing the people that are going to use the final software is as important as the code developped.
• User Involvement: We may think we know what people want on a software app, but we don't lose anything on asking. Talking with others can give you a better idea on what is the actual things you would want to see in a project.
• Product minimalism: Man, I just love minimalism. It makes everything so simple and neat. Just as your code should be! If it is simple and readable, you can detect errors faster!
• Focus on shipping software: Everyone must know they are developping the same thing. I know this sounds stupid, but if not everyone is on the same page, a project can't go right.

PD: I did cheat a little by copying the names of the titles, I'm sorry I don't have a perfect memory don't be all like this. See you soon, bye.

Surviving at the Software Industry. (2-3)

After a lovely questionnaire in chapter 2, chapter 3 shows us that we have to define development processes and elements needed for the software. If we have this things all put together, our project can move forward easily and the people working on it can be more productive.

We have to define first, “What is software process?” The survival guide gives us 7 different answers to define it.

·       Committing all requirements to writing.

·       Using systematic procedures for control.

·       Conducting technical reviews.

·       Developing a systematic Quality Assurance Plan.

·       Creating an implementation plan.

·       Using automated source code control.

·       Revising cost and estimates of schedule.

Process can turn rigid for the software developers, and each of the answers of steps can have some backlash that can make the project to no happen. We as project doers have to look forward for our team to use their productive time wisely. 

Thank you for reading! I shall give you an amazing gif from the filming of one of my favorite movies, La La Land. The guy on the green t-shirt is the director of the movie and he is a genius.

Surviving at the Software Industry. (1)

I liked the way the book "speaks" to me when I'm reading it, it feels like a guru giving you advices to succeed on the development of a project. Every software project that is considered low or medium size is achievable and optimizable.

The steps commanded by this guide are well explained and pretty basic. The first one is to recognize a software project’s essential survival needs, then it compared a project with a human and its needs illustrated by Maslow.

The author shows us how the needs of a software project look a lot like the human ones by adapting the Maslow’s Hierarchy onto Software needs.

We also learn about the Customer’s Bill of Rights, which are 7 actions that the customer has access to, such as objectives, time of development, features involved, change of requirements, project status, knowledge of risks, and ready access to deliverables.

On the other hand, he have the responsibilities of the Project Team’s bill of rights, these are the actions that everyone involved in the development of the project have to follow. To clarify priorities, to build and clarify the product definition, give the costumer ready access, etcetera.

What we learn today is that the 3 keys of success are communication, communication and communication. (Or at least for the success of the first step).

We shall continue with the second step soon! So I’ll keep you posted.

Welcome to the Ken course.

This is my post letting you all know that I'll be writing about project administration and evaluation here. You can check in "Temas" and look for the #TI2011 to see all my experience with the course. I'm actually excited to take it because my dad has given this class for a long time to the IIS. We'll see how this goes.

Con una cámara y luces de bengala.